TL;DR
In recent years, the tech industry has fervently championed the concept of “shifting left” in software development, advocating for early integration of security practices into the development lifecycle. This movement aims to empower developers with the responsibility of ensuring their code’s security from the project’s inception. However, while the intentions behind this approach are noble, the reality paints a more nuanced picture—one where the simplistic notion of solely relying on developers to uphold software supply chain security proves inadequate. In this article, I will present a complementary balancing approach: CISO-directed SDLC guardrails – automatic control measures that govern or enforce SDLC’s security policy.
Who Shift-Left My Cheese?
The shift-left paradigm, in essence, aims to address security concerns at the initial stages of development, expecting developers to proactively embed security measures within their code. It’s an appealing ideology wherein developers are tasked with identifying vulnerabilities and implementing security controls as they write and deploy their code.
However, this idealistic approach encounters significant challenges in practical implementation. Though proficient in coding, developers may lack comprehensive expertise in security techniques and best practices. Their primary focus revolves around meeting functional requirements, and expecting them to possess an exhaustive understanding of the ever-evolving landscape of cybersecurity is unrealistic.
Furthermore, time constraints and project pressures often result in trade-offs between security and meeting deadlines. In the haste to deliver features promptly, developers might inadvertently overlook potential security loopholes or employ less secure coding practices, leaving vulnerabilities unaddressed until later stages. At the end of the day, their KPIs are speed-oriented, and security will always be second for the majority of them.
Enter CI/CD Guardrails
This is where the necessity of implementing security “guardrails” in the Continuous Integration/Continuous Deployment (CI/CD) pipeline becomes evident. Guardrails act as automated checkpoints embedded within the development pipeline, ensuring that security measures are not solely reliant on manual interventions or individual developer expertise or motivation.
Guardrails serve as proactive gatekeepers, constantly monitoring and enforcing security standards, policies, and rules throughout the software development lifecycle (SDLC). These automated checks can encompass various security aspects, including but not limited to blocklisting bad packages, stopping code that contains critical vulnerabilities, fails static code analysis tests, or has problematic dependencies, and adherence to compliance standards or to secure SDLC policies (e.g., code review for every commit).
Using policy-as-code concepts, one can create almost any rule they can imagine to be implemented as a guardrail. Here are a few examples of guardrails rules in line with NIST 800-204D:
Exemplary Guardrails Rules:
- Developer Workstation
- Verify endpoint security suite of developer workstation
- SCM
- Verify branch-protection-rules: enforce multiple\specific reviews
- Verify that CI files are modified only by allowed personnel
- Verify secret scanning is in place and secrets are not detected.
- CI
- Verify code scanning is in place.
- Verify code scanning results are under a pre-defined bar
- Dependencies
- Verify open-source licensing.
- Verify open-source vulnerabilities are compliant with organization policy
- Artifacts
- Verify that the right identity signs artifacts.
- Verify final artifact vulnerabilities.
Guardrails, Not Handrails
By integrating guardrails into the CI/CD pipeline, organizations can systematically enforce security protocols and result in a secure product without relying solely on the developers to ensure comprehensive security measures. Taking into account that developers might bypass security measures for the sake of development pace, the guardrails approach makes these decisions impossible or at least visible, so they can be taken into account – both at the single-build level (e.g., decide on artifact trustworthiness) and at the organizational level (understanding what can and cannot be expected from the organization’s developers). Automated tools can flag or even block potential vulnerabilities or non-compliance issues before the new version is released to production or delivered to the client. After all, dealing with a security problem in the development phase rather than after delivery is indeed much easier, faster, and cheaper.
It’s imperative to recognize that while shifting left encourages developers’ involvement in security practices, it shouldn’t absolve other stakeholders—security professionals, DevOps engineers, and quality assurance teams—from their roles. If you are a product security, AppSec, DevSecOps, or CISO, then you already know that “shifting left” the responsibility to developers doesn’t take the accountability off your shoulders. Since most CISOs and their teams don’t come from R&D, software development environments were historically out of their sight. They would traditionally focus on operational security, network security, and cross-organization connectivity. The guardrails approach is a way to “delicately” get the CISOs into the wild west of the development environments, gaining back control over what they are accounted for. By “delicately” I mean “collaboratively”. Since product security is a joint effort of security and development teams, collaboration among these entities is essential in designing and implementing robust guardrails that fortify the CI/CD pipeline against potential security threats without impeding development speed.
Integration of shifting left principles with the establishment of guardrails in the CI/CD pipeline is a good balance. Developers remain responsible for writing secure code and understanding basic security principles while the security team decides the standards the product needs to meet to be released. Then, guardrails are automated accordingly into tools and processes to act as the safety net, continuously monitoring and reinforcing security standards and SDLC policy. Guardrails are an essential step toward products that are secure by design and by default.
Wrapping Up
In conclusion, while well-intentioned, the concept of shifting left falls short in ensuring comprehensive software security solely through developer involvement. To bolster the integrity and trustworthiness of the final software artifact, organizations must embrace the implementation of guardrails within the CI/CD pipeline. This combined approach not only elevates the security posture of software but also fosters a collaborative environment where developers, security professionals, and automation tools synergistically work towards a common goal of creating secure software.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
