DevSecOps Teams as Partners in Secure Software Delivery

In software development, security is often addressed late in the release process, leading to rushed decisions and potential oversights. DevSecOps teams can improve this by serving as partners in secure software delivery, establishing protocols, and providing feedback throughout the development life cycle.

Key moments for security involvement include before development, during development, and at the point of finding vulnerabilities. Before development, security engineers should decide what needs protection and which changes require extra attention. During development, security guidance and controls should be integrated into developers' daily tools. At the point of finding, the risk should be discussed, and a remediation plan determined.

Security guardrails provide clear behaviors for common risks, such as approved dependencies and secret scanning. Failed checks should provide understandable results, identifying the exposed file and required action. Developers usually know how to make safe changes, but an owner should take responsibility for any remaining risks after analysis.

Integrating security into the delivery pipeline involves adding checkpoints for secret, dependency, and configuration checks. Results should be tied to the version being prepared for release, and critical findings should trigger a clear decision, owner, and recorded reason. Before deployment, the application or container image should be reviewed for critical findings and open exceptions.

Pull requests are useful for detecting committed secrets, inspecting new dependencies, and flagging risky configuration changes. Automated security testing can help find potential issues early, but it may not always determine whether a vulnerable feature is used or exposed in a particular application. Before deployment, the built application, application image, or deployment configuration may be examined, and significant results should be discussed and agreed upon for approving deviations, assigning responsibilities, and setting time constraints.

Even if a low-priority finding exists with a corrective action plan, it cannot be considered an incident at the same level as a production credential. The example of a vulnerable library demonstrates how developers can determine the installed version and whether the application uses the potentially harmful method. Security tools can further investigate the issue, and if an update is available, it should be applied, and tests rerun.

If an immediate update is not possible, a mitigation and its approval date should be chosen, and the solution included with the release, stating the problem and how it was addressed.