What Does ‘Shift Left’ Mean if Every Process Is a Circle?

Synopsys sponsored this post.

When it comes to security in the software development lifecycle (SDLC), there has been confusion about whether to “shift left” or “shift right.” To clear up this confusion, the Synopsys Building Security In Maturity Model (BSIMM) is introducing a new term to optimize security testing in a DevOps lifecycle: “shift everywhere.”

The term “shift left,” which originated roughly 15 years ago, was almost immediately misunderstood to mean implementing security testing earlier in the SDLC. This missed the point entirely. “Shift left” was always meant to mean performing security testing as early as possible in each stage of the SDLC.

Shifting left in the software delivery chain enables managing security issues early and often, mitigating the risks associated with security defects being discovered in production and reducing the cost of fixing a security vulnerability. Shifting right means testing, identifying and responding to security problems immediately in production.

“Shift everywhere” encompasses both approaches.

Why Shift Everywhere?

Organizations can no longer perform all traditional SDLC security activities in compartmentalized phases. Instead, security activities need to be expanded across all phases as a continuous effort. That means conducting a security activity as quickly as possible, with the highest fidelity, as soon as the artifacts on which that activity depends are available. In some cases, that means shift left — to the beginning of the SDLC. But in other cases, it means shift right or to the middle.

For example, dynamic application security testing (DAST) should be performed as soon as you have running code. Configuration reviews should be performed as soon as you have defined or running environments. Collecting composition analysis events from production agents that show dependencies dynamically incorporated into running systems should be done as soon as you have deployed code.

Again, sometimes that’s to the left of what your organization is doing today, but often it’s to the right — maybe all the way out in production.

When to Shift Left

Shifting security testing to the left in the software delivery chain enables organizations to manage security issues early and often, as part of the pipeline, and mitigating the risks associated with defects being discovered in production. This approach reduces the cost of fixing a security vulnerability.

When to Shift Right

While a shift-left approach is beneficial, it cannot mitigate the risks of critical vulnerabilities making it to production. Organizations evaluating defect discovery tools and services are showing an increased preference for continuous event-based security telemetry throughout a value stream (rather than a single point-in-time analysis).

Some common approaches to shift-right testing include leveraging blue/green, rolling deployments, runtime application self-protection (RASP), run-time analysis and tracing tools — all of which provide for continuous event-based telemetry, leading to optimizing or hardening of the application and improving the security posture.

Feedback loops from event-based telemetry enable the setup of security hooks and triggers for pipeline stages. These triggers leverage vulnerability data, attack data, threat intelligence, etc., to enforce and augment log and incident data. This results in quick identification and remediation of production vulnerabilities throughout the development workflow, from build to production to operations.

Shift right also allows leveraging data from vulnerabilities found in production, to understand gaps in security controls within the development workflow and pipeline. These gaps can be mitigated through improvements in tooling, processes and training, or through added shift-right runtime protection.

Key Benefits of Shifting Everywhere

• Ability to address technical security debt
• Secure software design
• Improved code and software quality
• Reduced false positives
• Security attestation and immutable telemetry
• Automated compliance safeguards
• Improved incident-response capabilities

Conclusion

DevOps and DevSecOps are driving an IT culture change, including transforming the way organizations are handling security. This changing landscape includes engineering-led security integration, software-defined security, cloud configuration management, modern application frameworks, improvements in programming languages, container orchestration, adoption of microservices architecture, site reliability engineering (SRE), and more. All of this has resulted in the need for a “shift everywhere” security approach — leveraging telemetry, knowledge-driven intelligent pipelines, and tools that enable continuous security activities to spread throughout the development workflow, from build to operations.

Synopsys sponsored this post.

Feature image via Pixabay.