Aside from their primary area of focus, the reality is that every enterprise is now also in the software business.
CIOs and CISOs everywhere must now provide apps of high quality and solid security that are expected to rival those of Amazon, Google, or Meta. Updates must be released regularly to address security concerns, fix bugs, and incorporate new features and functions to remain competitive.
This constant need for innovation drives how companies build, run, and secure their applications.
During this continuous cycle of innovation, one crucial metric enterprises must keep track of is commit-to-deploy time, which measures the amount of time it takes for a commit to reach production. The lower the deployment time, the less expensive it is.
While this speed can benefit customers as they can enjoy app improvements faster, it presents a significant challenge to security teams to ensure that all deployments are tested for vulnerabilities.
Despite the advances in security platforms throughout the years and the effort to shift left, security is still the most time-consuming phase of today’s software development cycle. The problem is that anytime the application code is touched, it presents the opportunity for new vulnerabilities, PLUS the recurrence of past vulnerabilities to surface.
Consider that the average company uses over 200 applications, so the scale of the above security checks suddenly goes well beyond what almost any company can handle. In fact, because of this challenge, 79% of companies knowingly push vulnerable code to production. This process isn’t working, and we believe there is a better way.
Security-as-Code is the practice of leveraging machine-readable definition files that use high-level descriptive coding language to automate security behavior in the runtime.
Vulnerability injections in the CI/CD pipeline recently led to two popular open source projects from Apache and Google making headlines.
Zero Trust… for code?
When you consider other security approaches, such as Zero Trust, you’ll note that the vital principle applied is always to assume there is risk present.
Someone may have an elevated role that enables very sensitive permissions, but the Zero Trust approach does not rely on a point-in-time authorization. The concept requires constant recertification of results at every access request.
We bring this up because we believe there is a parallel to how organizations should approach application security.
If we genuinely want to address the security challenges within the CI/CD pipeline, security should perform continuously and immutably for every request in every application.
Otherwise, you trust that you are secure based on one point in time during the CI/CD pipeline. Think of it like zero Trust, but for code.
Immutable and continuous Security-as-Code
Applications secured with control through policy experience immutability where it’s impossible to introduce vulnerabilities in the pipeline or after.
In fact, with this approach, you are removing the burden of back-and-forth tickets to fix security flaws in the development lifecycle and taking weight off the shoulders of both your developers and security teams.
With Security-as-Code, there’s no code added now or in the future that can supersede the rules defined in your policy.
If development misses something in the pipeline, your policy catches and remediates it as your application executes. Security-as-Code lets developers focus on their applications, and security teams concentrate on security posture.
When the next major vulnerability like log4j happens, your security team can quickly add a new policy without involvement from development, providing instant time-to-remediation.
This Security-as-Code approach has enabled one organization to secure just over 2,500 applications impacted by log4j, in just a few hours, at scale.
So we are asking whether it’s time to shift our mindset from applying security to applications in the CI/CD pipeline to securing continuously and immutably with Security-as-Code.
To learn more about Security-as-Code, read The Five Business Reasons Why Every CISO Should Consider Security-as-Code.