Security as Code is a driving force for the current evolution of application security. It goes hand-in-hand with modern software development and the rise of Infrastructure as Code (IaC), but it is also helping innovation-minded organizations to better address and deal with the biggest security challenge seen in a generation.
The DevOps methodology has successfully broken down the silos between Dev and Ops and the Cloud has contributed toward empowering developers to start coding quickly. The infrastructure needed to house the code in the cloud can be easily configured. It’s this configuration step, however, that often exposes opportunities for mistakes and security vulnerabilities further down the line. To eliminate manual steps and to improve software consistency and security, these configurations become codified as Infrastructure as code.
IaC enables scale, speed, consistency, visibility, and traceability of changes made to each configuration. The challenge is that there are quite a few different levers for the organization’s DevOps and security teams to pull. With configuration settings embedded in different cloud services, containers, orchestrators, and in software build and deployment tools, it’s often difficult for dev and security teams to be confident about proper overall configuration.
By using automation, these different policies can be configured centrally and applied consistently to all projects. This innovation removes reliance on individual decision-making (and its clear potential for error) but in doing so, it creates a centralized target for anyone wanting to inject malicious configurations. Therein lies the danger.
Configuration can be automated, repeatable, and follow standards or, it can be a mess of one-offs created without fully understanding the impact of the choices. Either way, security must be considered for the hardware, the apps, and the infrastructure that the apps depend on as they’re developed, deployed, and used. With settings codified as IaC, you must treat THAT code with the same rigour you would for application code.
The catalyst here is automation and how software time-to-use will be accelerated.
Because the IaC is automated, by nature it happens almost instantly. Now, your teams can push both infrastructure and code to production in one step. But if it’s not secure, vulnerabilities can be rolled out with the code with almost no time to test configuration integrity. This fact necessitates automation of security checks, and the need to bake them into both the software assembly and deployment processes, rather than them existing as separate efforts that have to be handled by separate security teams. So, in the end, IaC begets Security-as-code.
IaC: new thinking for software security
The Solarwinds attack1 made executives, security professionals and developers everywhere stop and reflect on the security of their organizations’ software factories. The attack highlighted a clear failure to protect the SDLC process.
In the exploit, the hackers deployed malicious code into the Solarwinds Orion IT monitoring and management software used by thousands of enterprises and government agencies worldwide. SolarWinds then unwittingly sent out software updates to its customers that included the hacked code. Injected during the build process of the Orion app, the code effectively created a backdoor to SolarWinds customer’s IT systems, providing access for malicious intent.
Europe faces similar and growing challenges. Research into threat landscapes published this week by the European Agency for Cybersecurity (ENISA) reckons that there will be four times as many supply chain attacks in 2021 as last year.
The most damaging attacks tend to rely on complacent internal attitudes towards security hygiene (think patches not completed or passwords not being changed regularly) using tried and true exploits that have been around for years. According to media coverage of the incident, Solarwinds admin relied on a simple password and didn’t change it. Moving to automated processes could ensure regular password rotations while secrets detection can search rigorously for hardcoded passwords, especially prevalent with APIs that connect different apps together.
As a result of the SolarWinds attack, followed by the similarly high-profile Continental gas pipeline attack, President Biden issued an Executive Order for cybersecurity. Everyone in the software community should take notice since this intervention could potentially trigger a level of effort on governance, testing and security that has not been seen since Y2K planning — where every application was inspected for how it handled date variables and many required re-architecting. This new focus on securing the software supply chain promises a similar level of introspection.
Where to start security governance and testing?
Fortunately, there are key steps your organization can take − and as a by-product, this automation will speed your software’s time-to-delivery.
You’ll need to think about and detail the processes and the policies for each step. As you define the policies, you must consider a raft of new questions. For instance, to what extent do you test your source code. Every app? What are the exceptions? Who can approve exceptions? Do you test your containers? When? By whom? Who has access to your software factory? What are they allowed to change?
It helps to break down the software security effort and resourcing into three main areas:
- Deliver more secure code − test the code you create to identify and remove vulnerability risks. Determine policies for what scans are used and for what scope of your application portfolio. Ideally, you’d want to run multiple types of scans, at the code commit and at merge to the main branch stages. Consider tools that have all these scanners built in to eliminate management of a complex tool chain integration. Next, determine policies for actions required when vulnerabilities are identified.
- Secure the app’s surrounding infrastructure − test for misconfigurations then monitor for unanticipated changes. Consider:
- Containers – what’s in them (libraries and dependencies).
- Orchestrators (e.g. Kubernetes) – configured to direct how, where, and when containers run, governing which apps can talk to which other apps, and what compute and storage resources are each app allowed to consume.
- Cloud services – the environment hosting virtual machines and containers.
- The IaC (coded configurations) such as APIs, packages, Helm charts, Terraform, etc. As monolithic apps are increasingly broken into microservices, authentication and authorization take on a whole new dimension – and embraces greater use of APIs. You must test them and, ideally capture, store, and view all API calls for your organization’s audit purposes.
- Secure the software factory itself – secure the software factory itself against malicious intervention. The CI pipeline is essentially your software assembly line, so managing access to it, whether human, machine, and API, is fundamental.
Extend Apply Zero Trust principles to this work. This approach will include things like ensuring least privilege access to your DevOps tool chain and the application’s infrastructure. In addition, you will need to gather an inventory of infrastructure elements such as registries, package managers, etc., and assess the different levels of access allowed. Access Management must consider this new, broader scope.
An automated CI/CD pipeline has the advantage of consistently applying additional common controls for compliance such as separation of duties, merge approvals, and more. These capabilities will in turn also simplify internal security audits.
Security as Code Can Accelerate DevSecOps
Modern software applications require the latest application security methods, even beyond simply shifting left. As development cycles are accelerated, security as code becomes paramount. With this change comes added benefits not possible with traditional more siloed methods – velocity, visibility to risk, control. Security-as-code strategies enable organizations to start preparing now for this evolution of application security by truly embedding security into their software factory from end to end.
Cindy Blake, GitLab
Cindy Blake is the senior security evangelist at GitLab which is leading the DevOps market with an innovative single application approach for the entire software development lifecycle. She collaborates around best practices for integrated DevSecOps application security solutions with major enterprises. Previously, as part of Hewlett Packard Enterprise (HPE) Fortify team, she led early third party research on the intersection of development, security, and operations.
Find our interview with Cindy about installing DevSecOps in our YouTube Channel: https://www.youtube.com/watch?v=m0-3VE42fPs&t=408s