This article was authored and submitted by Mark Lambert, VP of Products at Parasoft. It was originally published on the company’s blog and available in its entirety HERE.
The new focus on integrating security into the application development process has resulted in government agencies and their contractors embracing a new method of development that has been called DevSecOps or SecDevOps. And, while these two terms seem similar and are often used interchangeably, there is a difference.
It might sound like semantics, but the order of words carries all the weight. How do we culturally shift the way we address security? We start by treating it with the gravity it deserves, and start building it in, at the very beginning.
Here is how a SecDevOps approach to development differs from DevSecOps and how delivering secure software is easier to achieve when security is an integral part of development, from the start of the software development process rather than as a gate at the end of the delivery pipeline.
What security looks like in DevSecOps
Despite the increased focus on security, it’s challenging for software teams to build security into a process and pipeline. The pressure to complete projects on time and within budgets often overrules other considerations. As a result, we tend to see security added as the last gating step for a release candidate.
As security knowledge is typically scarce, limited to a few individuals in an organization, these individuals are often grouped into a centralized security team. The security team is tasked to test the product using their “magic box of tricks,” to find vulnerabilities in the release candidate before deployment.
When the team, inevitability, finds a vulnerability, they pass the “bad news” back to the development team, but, because the development team doesn’t have the security training or knowledge about how to use the tools that the security team are using, the security team is often seen as “bad guys” because they are now holding up the release because of “some security vulnerabilities.”
So, what’s the typical reaction of the team?
Let’s face it, it’s tough to get important security fixes, controls, and coding standards into a project that’s “done and dusted” as far as the development team is concerned. What happens? The product goes out the door with known, and unknown, security vulnerabilities with possibly some promise to “fix them in the next release.” This is what you get when you put security after development – “Dev” then “Sec” then “Ops.” While this isn’t the intention, this is the reality in many organizations. Consider a better approach described below.
What security looks like with SecDevOps
Security controls, guidelines, coding standards and policies must be integrated completely into the software development process. This is done by making security part of the process and pipeline from the beginning – “Sec” then “Dev” then “Ops.” The security team — or perhaps an architecture or senior developer specialized in security — defines the necessary policies upfront for the team.
These policies might consist of secure coding standards, rules for avoiding insecure APIs and poor encryption, instructions for using static and dynamic analysis, and testing guidelines. The goal is to have the developers working towards more secure software as part of their daily routine and automation helps make this a reality.
With automation, you can shift-left your approach to security for a SecDevOps strategy that looks something like this:
As security is now baked in at the start of development, the team will naturally become more proficient in security and fewer security vulnerabilities will be found at the end of the pipeline.
The vulnerabilities that do make it through can then be investigated and the results of root cause analysis used to improve on the security policies and guidelines – essentially improving the outcome as each cycle progresses.
Driving iterative improvements to the policy results in less disruptive late cycle escalations, and looks like this:
his incremental and integrated approach works much better than trying to tack on a security audit at the end of the project.
Making security a part of quality with a security-focused workflow
There’s no way around the fact that security adds an additional requirement for developers, but how you manage the impact of this work is what makes the difference between an on-time, secure product, and a late, insecure one. A critical requirement is to integrate security into the existing development process, which you can do by integrating a suite of CWE-compatible testing tools – like those provided by Parasoft — to make security a part of quality and the overall workflow.
The workflow starts with the secure coding policy. The Architect or Lead creates a configuration — possibly based on coding guidelines such as CERT, CWE, OWASP, UL-2900 or PCI DSS — for the rest of the team to leverage directly within their IDE. This gives the developer the ability to check the code locally on their machine before committing to source control – catching and fixing security violations where and when it’s cheaper and easier to do so.
The same configuration is then leveraged by analysis executed as part of the build process. This comprehensive analysis goes beyond the scope of the developer’s locally modified code and provides a safety-net to gate the delivery pipeline to ensure that insecure code does not get promoted to later stages.
Lastly, the results of the analysis are sent back to the developer’s IDE via the centralized reporting and analytics dashboard, where progress can be tracked, course corrections made, and audit reports generated in real-time.
The full SecDevOps workflow looks like this:
Managers and security leads can now assess projects based on security standards such as CWE, in the central dashboard. These dashboards can show trending information and answer questions, such as, “Is the project improving or getting worse?” or, “Which areas of the code are causing the most issues?”
Being able to answer these and other questions, and take action, transforms the development team from DevSecOps to SecDevOps.
In my next article on the GovDevSecOpsHub, I’ll take a deep dive into the three challenges that arise within an organization when they don’t shift security to the left in the application development process, and provide solutions.
To read Mark’s original article in its entirety, click HERE.