What is security as code?
Security as code is a driving force in the future of application security. According to O’Reilly, security as code is the practice of building security into DevOps tools and workflows by mapping out how changes to code and infrastructure are made and finding places to add security checks, tests, and gates without introducing unnecessary costs or delays. Developers can define infrastructure using a programming language with infrastructure as code. The same needs to happen to bring security to the speed of DevOps.
At a basic level, security as code can be achieved by integrating security policies, tests, and scans into the pipeline and code itself. Tests should be run automatically on every code commit, with results made immediately available to developers for fixing. By bringing security scans to the code as it’s written, teams will save both time and money by streamlining the review process later in the software development lifecycle (SDLC).
Why is it important?
Security as code is key to shifting left and achieving DevSecOps: It requires that security be defined at the beginning of a project and codified for repeated and consistent use. In this way, it gives developers a self-service option for ensuring their code is secure.
Predefined security policies boost efficiency, and also allow for checks on automated processes to prevent any mishaps in the deployment process (like accidentally taking down the whole infrastructure because a problem wasn’t identified in a staging environment).
Six security as code capabilities to prioritize
Francois Raynaud, founder and managing director of DevSecCon, said that security as code is about making security more transparent and getting security practitioners and developers to speak the same language. In other words – security teams need to understand how developers work, and use that insight to help developers build the necessary security controls into the SDLC. Developers can reciprocate by staying open-minded as they adopt new tools and practices to boost security during the development process. Here are six best practices and capabilities to build into your pipeline:
- Automate security scans and tests (such as static analysis, dynamic analysis, and penetration testing) within your pipeline so that they can be reused across all projects and environments.
- Build a continuous feedback loop by presenting results to developers, allowing them to remediate issues while coding and learn best practices during the coding process.
- Evaluate and monitor automated security policies by building checks into the process. Verify that sensitive data and secrets are not inadvertently shared or published.
- Automate complex or time-consuming manual tests via custom scripts, with human sign-off on results if necessary. Validate the accuracy and efficiency of test scripts so that they can be replicated across different projects.
- Test new code within a staging environment to allow for thorough security and low-impact failure, and test on every code commit.
- Scheduled or continuous monitoring should automatically create logs (or red flags) within a review dashboard (such as GitLab’s Security Dashboard feature).
Security as code is a best practice for a bigger goal
Security as code gives pragmatic meaning to the concept of DevSecOps, but it should not be your end goal. Ultimately, security as code is a means to get more people on board with integrating security throughout your SDLC. The idea will feel familiar to developers who have practiced infrastructure as code, and it provides an opportunity for security to step into the fray both to better understand software development and to help design the policies that will be codified in the process.
As your team works its way toward becoming a well-oiled DevSecOps machine, security as code will inevitably present itself as a smart solution within a complex endeavor.
GitLab’s DevSecOps methodology assessment
There’s a lot to cover when standing up a DevSecOps process – so to help you master the key elements, we created a DevSecOps methodology assessment. Score yourself on 20 capabilities, and then use those scores to understand your DevSecOps maturity level, and determine what actions your team can take to bring your DevSecOps to the next level. Download the assessment here.
