If we’re to use Infrastructure-as-Code as a blueprint for Security-as-Code, there are three key pillars that any SaC solution needs to exemplify:
1. Immutability
The rules you define should remain accurate to prevent vulnerability regressions with each deployment. Security must be continuous to achieve immutability – not at a single instance like in the CI/CD pipeline.
To perform security continuously, the protection applied to your applications and APIs must be inseparable. Due to this nuance, utilization of the runtime or VM is necessary.
2. Scalability
Cost and human capital are the reasons current security solutions don’t scale. WAFs and RASPs, for example, are essentially massive data pipelines that ingest, analyze, and make assumptions on HTTP payloads to determine risk.
This focus on HTTP payloads, a lagging indicator, results in false positives and negatives, exasperating the scalability issues of existing Security solutions.
Static analysis tools only do marginally better by telling you what code to fix. Then your teams are left with the manual task of patching the vulnerabilities.
The only way to improve security scalability is to automate the process of patching code. Compilers have operated on this philosophy for decades to improve performance.
The same philosophy can also correct known vulnerabilities and insert security rules that block unknown vulnerabilities (zero days). When you fix the vulnerable code, you eliminate false positives and negatives and the need for expensive hardware.
This decreased friction enables security teams to, for the first time, scale with modern software development.
3. Performance
In theory, an infallible security solution works, but we need to meet business demand in the real world. Because of that, most security solutions recommend running in sample mode, where only a handful of requests are protected.
Companies shouldn’t have to choose between being protected and remaining competitive.
Companies no longer have to make this choice when your security solution has proximity to the application and APIs through living in the runtime or VM and adopting the philosophies from compilers.
Security-as-Code implementations average less than 2% performance impact on average at scale.
