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.
