A key component of DevOps is the ability to support software branching and merging. Software branching enables software development teams to develop multiple parts of software at the same time, to have multiple releases for various platforms, and to help manage larger software teams with many different roles and responsibilities.
In an application security context, there’s a layer of obfuscation when it comes to tracking visibility at the branch level. Security testing in many enterprises still occurs only in the release branch. There are a number of reasons for this, including the cost and complexity of managing security issues in multiple versions or branches.
Feature branches enable developers to work together as well as individually with a copy of the main codebase. Projects are often worked on for hours, days, weeks, or even months for some products. When a developer is working on a specific feature, when is the best time to tell them about a potential security flaw they are introducing? If you answered while the developer is still developing the feature, you are correct.
Security analysis must break out of main branch / release branch style of compliance scanning and be performed earlier in the life cycle so that developers can get security results delivered to them while they are still in the context of developing the feature. They are much more likely to fix issues immediately without needing to remember to do it later. But although this may seem simple to do, there are factors that introduce complications in the triage process.
We can’t just run a security scan in a feature branch and deliver the raw results to a developer. The security tooling must be aware of the full historical context of any auditing that has occurred previously for any existing security issues (or false positive or contextual filtering). It is not helpful for a tool to re-identify existing or known bugs that have been deferred by auditors in past audits.
Developers typically want to be told of any security mistakes, especially when they are told efficiently and with past audits applied. These mistakes can be added to a consolidated list of security issues in their branch to ensure they are remediated before merging the code into main. Enabling a developer to make the secure choice more easily and shifting visibility downstream in the SDLC reduces security/developer friction, and ultimately enables organizations to build quality software.
Empowering developers with this level of visibility improves code security, but it also enables developers to build better products. Using feedback loops and communicating critical vulnerabilities and fixes in the developer context ensures that they have the information needed for remediation with minimal friction to the DevOps process.
Providing this level of visibility is essential to effective DevSecOps. Code Dx® offers many features that enable DevSecOps and help development teams perform audits and analyses for multiple project branches within individual projects. This provides more flexibility in managing software audits and fixes, integrating security decisions within source code management (SCM) workflows, and limiting disruptions and inefficiencies because of multiple code commits.
Code Dx assists DevSecOps teams with