Forget DevSecOps and ShiftLeft

In this article, we're about to spill the beans on why this approach rocks, answer some burning questions, all while keeping our magic wand at the ready.

The Traditional DevSecOps Approach

DevSecOps, which emphasizes integrating security into the development process, has been a buzzword in the industry for some time. While the intentions behind it are commendable, the practicality of implementing it can be a challenge. The traditional DevSecOps approach involves running security scans and tests throughout the development process. Unfortunately, this can lead to several issues:

1. Development Tool Parity: Developers often face discrepancies between their local development environments and the security tools applied during the build pipeline. This can result in a false sense of security when code is committed, only to discover vulnerabilities later in the process.
2. Alert Fatigue: Continuous security scanning can generate a flood of alerts. When everything is an alert, it's challenging to distinguish critical issues from noise, leading to alert fatigue and potentially missing real threats.
3. Delayed Feedback: Email or alert-based notifications for security findings can disrupt the development workflow. Developers may skip or overlook them, causing vulnerabilities to persist until deployment.
4. Production Incident vs. Defect: Discovering security flaws in production is far from ideal. It transforms what was once a defect into a security incident, often with significant consequences.

Gates of Glory

We're talking about quality gates. Where code goes to die, or where security swoops in at the eleventh hour, capes and all, to save the day or tell you where you failed to meet some unwritten expectations.

Better Quality Gate

What Quality Gates were always meant to be. To provide quality and security assurances, when everyone considers the release is ready, that all agreed requirements were known up front and have been met.

Imagine a scenario where security is not a constant nag but rather a silent guardian that only springs into action when it's truly needed. This is where real quality gates come into play. Rather than scanning every line of code as it's pushed, it is assumed (and trust is given) that the developer did that already, quality gates are deployed only when the entire release is considered ready. Why? Because:

1. Devs Already Have the Tools: Developers are armed with the same security tools locally as the code is written, and they ran the tests when it was committed, eliminating the need for repetitive scans later when the developer isn't in a state or context to get nagged about the results.
2. Alerts Are Higher Value: When everyone agrees that the code is 'ready,' security alerts become more meaningful. They serve as crucial assurance rather than mere distractions. That is, if any alerts a raised at all. Remember, the requirements are known and developers already met them all during code commit workflow, so testing later at a quality gate should rarely raised any issues to block relases.
3. Feedback is already in the Dev workflow: Feedback should be where it matters most - within the developer's workflow tool, like an IDE or Git as pre-commit hooks. This ensures that defects are seen and addressed when the developer is in the needed context and already working on the exact problem anyway.
4. Production Incidents, Not Defects: If a security issue is discovered in production, it's no longer a defect; it's a full-blown security incident. The response should be treated appropriately. Meaning that is not something to interrupt software developers, security and operations (Platform, SRE, Sysadmin) teams are already responsible and prepared for this - developers are meant to be developing to a deadline or expected to be in an entirely non-production context.

To make this approach work, a few key elements must align:

• Security Teams in Dev Workflows: Security teams should learn to operate security tools within developer workflows. This means being where developers are, not demanding developers to be where they are.
• Developers Seeking Security Help: Developers should proactively seek security assistance or learn to operate security tools in their IDE and Git hook workflow. Collaboration and intentional preparation is the key to avoid disruptions.
• Ops Assurance: Operations teams must ensure that these practices are followed for all production releases. Security can't be an afterthought. Anything less means security incidents, and potentially friction with development teams as releases are perceived poor quality at no fault of the developers.

Answering Tough Questions

• Can security continue to spend time messing around with the whole "force Sec into DevOps" and the ramifications of friction and triage?: Instead of constant scanning, security teams can focus on more strategic tasks like patch management, onboarding, threat hunting, penetration testing, architecture review, and identity management.
• Do Developers Need Security Skills?: Not necessarily. They need to understand how security tools in their workflow function but don't need to become security experts. These tools belong in the IDE and developers get feedback in their own context.
• Shouldn't Security teams ultimately be supporting the business (and therefor Devs)? Why do they constantly intervein, interrupt, and re-prioritise outside the business functions and during R&D?: Security teams can better support the business by aligning security goals with business objectives. Devs benefit from streamlined workflows, not roadblocks. It's essential to acknowledge that not all security teams are created equal. Some might not even be necessary in their current form. If the security team member wants to be involved in development, then the role int he security team becomes a development role in reality and that security team role is more about entitlement and a power play, rather than being a productive contributor to development.
• If security alerts coming from Ci/CD pipelines require triage, that inherently happens as unplanned work and not within the natural flow, then isn't that (ShiftLeft) a project risk?: The traditional approach inundates developers with noisy alerts, most of which turn out to be false positives. This not only disrupts development but also lacks the necessary context to be actionable. Time spent on triage becomes a project risk and hinders feature delivery. Dealing with security findings can be a nightmare, especially when secrets leak. The steps are intricate and time-consuming. But what if we prevented these defects from entering Git in the first place?

Conclusion

Let's admit it, the traditional security approaches (now include failed experiments DevSecOps and ShiftLeft) can sometimes feel like dealing with an overbearing parent. In the hacker culture, we value efficiency and innovation. So, why not apply these principles to security?

Just forget about fighting devs for their time and attention with the traditional DevSecOps approach. Instead, seamlessly integrate security into developer workflows and let security be a silent guardian, only stepping in when it truly matters. It's time to get security out of the way and into the IDE and use Git hooks, where it can quietly do its job without disrupting the development process.