Why DevSecOps Best Practices Are Important
Best practices. It’s a term thrown around a lot in security and software development. While you see them talked about everywhere, they’re called best practices for a reason. When you walk into a new job or engage with a new client, you can quickly spot the ways in which they aren’t following industry best practices for DevSecOps.
For instance, in a new company you might spot that security tests are done on an ad-hoc basis instead of being automated. You might come across a tool that’s been out of widespread use since 2018. You could join a standup meeting and come to realize that no one’s taking notes, referring to a timeline, or even saying anything useful.
Following best practices allows everyone to work more effectively together. It ensures that we’re keeping up with what industry leaders are doing. It is a safeguard for our business’s future, that we will be able to provide quality products and services that people expect from a professional operation.
What are DevSecOps best practices?
“48% of organizations regularly push vulnerabilities into production.” - Scaling Security for Modern Software Development Using Application Security Operations
Best practices provide a recipe for the best outcomes. We can compare following industry best practices to following a recipe. If a recipe says to ‘stand overnight’ and you just let the food sit for an hour or two, you won’t get the best result. If you substitute honey because you’ve run out of sugar, food might not taste or bake the same. Likewise, not adhering to guidelines generally recognized by the security industry can compromise the security of the software and data entering or leaving your kitchen.
The difference between DevSecOps best practices and following a recipe is that the software development industry is constantly evolving. This means that staying on top of what’s best practices right now can be tricky. What’s considered the gold standard for one year might be replaced by a disruptive technology, process, or concept just a short while later.
Staying up to date with best practices involves investing time into learning and development, in uncovering the latest industry advancements, and in investing money into new solutions where they fit the business. Continuous improvement is a cornerstone of any successful business.
DevSecOps was born from DevOps best practices
DevSecOps is a relatively new field, built out of a need to integrate security earlier on in the DevOps-led software development lifecycle. Thanks to the maturation of processes and tooling in DevOps, this ‘Shift Left’ in security has been possible as an industry movement. But without adopting DevOps best practices, trying to do DevSecOps can be somewhat effective at best.
DevSecOps is built on the back of DevOps best practices, including core practices like continuous integration / continuous deployment (CI/CD), bringing together mixed teams of people from both operations and software development, and building out infrastructure as code.
Adding security into the mix is, in its simplest form, embedding security elements across those DevOps best practices, rather than having them as separate or bolted-on activities.
Read: 4 Tips to Make Agile DevSecOps a Reality blog
DevSecOps best practices
Have you rolled out these DevSecOps best practices?
Automate as much as possible
Whether through scripts, tooling, or orchestration platforms, security across the software development lifecycle should be as automated as possible, to fit in with DevOps workflows, optimized for speed of development. Techniques and tools like Software Composition Analysis, Static Application Security Testing, Interactive Application Security Testing, Dynamic Application Security Testing, and more can be integrated into the workflows of development with the right approach.
For developers to be able to integrate security practices into their workflows effectively, those security elements must be dev-friendly. That means automating manual security steps as much as possible, integrating security tools into developer environments and workflows, and ensuring their time is not spent chasing and analyzing security issues. Seeing the right issues in the tools developers already use should be a relatively easy, repeatable process, so they can fix issues where they lie.
Role-based reporting and alerting based on tool aggregation
It’s a bit of a mouthful to say, but role-based reporting and alerting based on tool aggregation is essential to getting the right security information to the right people at the right time. Aggregating issues from your security scanning tools ensures that the right alerts are surfaced while minimizing unnecessary alerts from often-noisy tools. This is essential to developers actually paying attention to the tool, and not simply ignoring it or switching it off due to alert overload. An Application Security Orchestration and Correlation tool is a good fit for this purpose. Security leads need a different view on security alerts than developers, as do other stakeholders such as project managers, so there should be distinct, and preferably configurable, views for these different roles. And finally, these reports should be real-time and on-demand.
Audit with a DevSecOps maturity model
To know where you stand in terms of industry best practices, you can audit your business against a DevSecOps maturity model. OWASP’s DevSecOps Maturity Model is a good starting point for any organization looking to benchmark their operations in DevSecOps on a mission to do better in practice. The evaluation criteria in the model go across build, deployment, patch management, design, education and guidance, process, application hardening, development and source control, infrastructure hardening, logging, monitoring, application tests, consolidation, dynamic depth for applications, dynamic depth for infrastructure, static depth for applications, static depth for infrastructure, and test intensity. You might also like to take a look at the DevSecOps playbook, a “step-by-step guide to implementing a DevSecOps program for any size organization” by Paul McCarty of SecureStack.
For auditing your software security program specifically, the Purple Book Community has just released the latest maturity model built for security professionals by security professionals: the Scalable Software Security Maturity Model.
How can ArmorCode help?
"By 2026, over 40% of organizations developing proprietary applications will adopt ASPM to more rapidly identify and resolve application security issues." - Gartner Innovation Insight for Application Security Posture Management (ASPM) report
ArmorCode is designed to help organizations build software assets at the speed of DevOps, but with security built in, as it should be. The ArmorCode AppSecOps platform unifies AppSec and infrastructure vulnerability management to normalize, correlate, and orchestrate findings from all your security scanning tools. Our platform provides the visibility, prioritization, automation, and reporting environment that is impossible to achieve through a combination of security tools, scripts, infrastructure as code, and siloed reporting alone.
We’ve helped companies transform their AppSec programs and processes to save a significant amount of time and effort - and we’d love to show you how we do it. Get in contact for a demo to check out our platform today.