Common sense DevSecOps tips for developers

Source – jaxenter.com

DevSecOps might be the latest in a long line of tech buzzwords, but it’s actually a fairly practical way at promoting secure tech practices while uniting different spheres of production and operations. But getting into a DevSecOps mindset requires serious collaboration to change processes and tech for the better.

As DevSecOps is rapidly becoming the preferred approach for organizations, it becomes even more important to take a moment and make sure everything is heading in the right directions.

According to the tech-based research firm Gartner, integrating security into DevOps requires changing mindsets as well as practices. Collaboration is key to make the “Sec in DevSecOps silent”.

Challenges for DevSecOps

Information security isn’t sexy. Sorry. It’s just isn’t. Fortunes are made on new products with new IT-enabled capabilities, not on making sure all your Java library dependencies are up to date. This means that vulnerabilities are often ignored until disaster strikes.

In the development process, security is often an afterthought at best. However, organizations and enterprises have a responsibility to their users to create safe and reliant applications, whether or not they use DevOps.

That being said, information security should be adapted to DevOps processes and tools if organizations are to fully synthesize Sec into DevOps. Equally, neither should perfect security be pursued to the point of hindering digital business.

Recommendations

So, what should a DevOps organization do? Balancing speed with security is a tough tightrope to maneuver across. It’s easier said than done, but most of these recommendations are pretty common sense.

• Integrate security and compliance testing into the DevOps. If you make it so that developers can manage data security bits without ever having to leave their CI/CD toolchain, then you’ve removed a major barrier to ensuring data security.
• Know where your components are from! If it’s open-source, check for vulnerabilities and misconfigurations.
• Be open to new tools and approaches.
• Scale your infosec team into DevOps with a security champion model.
• Test your automation scripts, templates, images, and blueprints to the same level of assurance as your source code. Maintain a level of assurance and stick with it! Just don’t get too crazy about it, perfection is a myth.

Top 10 tips

That sounds all very well and good. But how does it work on the ground? If you’re trying to put the Sec in DevSecOps, it’s not exactly straightforward. Or is it? Again, a lot of these tips seem common sense. You’d be surprised how many people forget the basics sometimes.

1. Don’t try to fit a round peg in a square hole. Adapt your testing tools to your development team. Make it easy for developers to use the security testing tools. If it’s difficult and a pain, no one’s going to go out of their way to make it work, no matter what the goals are. If the Sec is implemented properly, it is invisible in the process.
2. Perfection is the enemy of good. Quit trying to eliminate every security vulnerability during testing. You’re not perfect and it’s basically impossible. We’re not suggesting you ignore security entirely; just accept that there may be some minimal security flaws and move on.
3. Triage your troubles. Focus on the big things and then work your way down on the critical list of security flaws. This should be self-explanatory, and yet.
4. Your custom code isn’t perfect either. All applications have a certain amount of custom code. And that means those vulnerabilities are hard to track down. You should expect to have some changes. Sorry.
5. Your developers aren’t security experts and that’s okay. Obviously, basic security training for developers is important and necessary. That being said, you can’t expect them to become cybersecurity experts on the basis of a 2-day training course and some PowerPoints. This basic training should mitigate a certain amount of user error, anyways.

6. I need a hero. Security champions mean every organization has That-One-Person-Who-Knows-About-Security. If you nominate a few people to the role of security champions, then you can clarify standards and requirements across the whole organization.
7. Don’t use sketchy sources. Again, this should be self-explanatory. Try to minimize the use of vulnerable components from the get-go. Your developers should know better.
8. Don’t fuss over the paintjob if the foundation is rusting away. Infrastructure is important. It’s necessary to make sure that the source code controls apply to the underlying infrastructure as well.
9. Keep clear records and consistent code. As always, documentation is key; it’s good to know who changed what, so you can fix errors and ensure consistency across all iterations.
10. Lock your infrastructure up, yo. At no point should one single person have the ability to change the infrastructure once in production. That way leads to madness and system errors. Instead, all changes to the infrastructure happen in development. If something catches fire, then those latest changes can be rolled back.

Integrating security into DevOps isn’t the easiest, but it’s certainly a worthwhile endeavor. And, if you’re having troubles, just remember to keep calm and code on.