SecDevOps
DevSecOps vs SecDevOps:
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. (there is a difference).
What security looks like in DevSecOps
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, the limited 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 is the typical reaction of the team?
This is what you get when you put security after development – “Dev” then “Sec” then “Ops.” While this is not 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.
The goal is to have JVGlobal-IT developers working towards more secure software as part of your agencies 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, looks like this:
JVGlobal-IT thoughts are, “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
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.
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
In short, 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?”
JVGlobal-IT: Being able to answer these and other questions, and take action, transforms the development team from DevSecOps to SecDevOps.
Call us today!