Every week the media publishes something about a particular company getting pwned or hacked.  In today’s world of digital transformation and an ever increasing presence of the Internet and technology the world of cyber security has become a big deal.  Everything is connected and everything can be hacked. Application development can be a long, complex process that can potentially expose different types of security issues as multiple developers are working on a project.  In addition, other areas of information technology can add additional complexity to the mix.  It’s no longer just about the code, it’s about the servers, the network and everything in between.  Solving the problem of securing an application is everyone’s responsibility and no longer relegated to “just a developer”.  Because more people are involved and the process spans the entire SDLC of application development, I’ve started seeing the phrase “devSecOps” quoted more frequently hand in hand with software development.  The goal of devSecOps is getting the developers to think more about security standards and principles by integrating it into the very bloodline of their development process.

Security + devOps == devSecOps

“With great power comes great responsibility”

One of the goals of devOps is spreading ownership of working software in production across the entire team and not perpetuating silos of excellence.  Automating our development and delivery process has increase delivery cadence and reduced the feedback loop between each area of constraint within the SDLC.  Adding security to our automation stack of tools is no different.  Every company wants a strong set of security policies and standards, but nobody wants to be the constraint that slows down the delivery process.  Security has to be part of the process and it has to be automated if we want to get the full benefits of the Agile process of software delivery. The GOAL of devSecOps is baking security testing and vulnerability scans directly into you development and delivery process.  To that end, there are multiple tools out there to help us move our code along the pipeline.

  • Infrastructure Best Practices: The cloud ecosystem has tools built into scan your infrastructure looking for security best practices that should be taken advantage of like the Azure Advisor.
  • Static Code Analysis: Tools like sonarQube do a great job of scanning source code and identifying potential vulnerabilities in your source code as well as the various open source libraries you might be using in your application.  Gated check-ins or nightly builds must use these tools to identify potential issues long before they get “baked in” and become expensive to remediate.
  • Automated pen testing tools: Things like the OWASP Zed Attack Proxy (ZAP) should be used on a regular basis to scan your sites looking for the low hanging fruit that hackers love to exploit.

There are of course new tools coming out just about every week since this is such a hot topic and everyone wants to jump on the bandwagon.  But security starts on day one before we ever write a single line of code.   If you’re not training developers on secure coding practices from day one, you’re leaving yourself open to a well intentioned but naive coder who will leave back doors in your system because they never thought it would be “used that way”. Even with training, things can slip through if you’re not vigilant.  That’s the main reason you need to make sure that you are scanning and testing your product throughout the delivery pipeline line up to and including production with a regular cadence.  AND of course that the results of those scans must be given back to the developers as quickly as possible in order to have an agile feedback loop.  Software, automation, the Internet, apps… These are all part of the new digital economy and must be secure.  Automation within our software delivery pipeline helps us to ship code faster, with higher quality and more security only if it is used.