The recent Solarwinds supply chain attack made us all question the security of our software development, deployment, and use, particularly in the era of DevOps and cloud-native applications. Security teams often struggle to ensure security is not an afterthought as software is developed faster, released more often, and uses tools that have been beyond the radar of the security team. In fact, when NIST describes DevSecOps they say that DevOps is being embraced "often without a full understanding and consideration of security," putting CISOs at a disadvantage right when they are being tasked with ensuring a secure software supply chain.
The problem with a traditional AppSec approach
CISOs often struggle to bridge large investments in traditional application security (AppSec) tools with more modern approaches that embed security into the software factory itself. Traditional AppSec approaches lead to several challenges:
- Cost: One tool for each scan type can get expensive
- Integration: Integrating point solutions into CI toolchains requires ongoing maintenance
- Trade-offs: Emphasis on triaging vulnerabilities and prioritizing risk of CVE findings (signature-based) over remediation
- Legacy: Limited comprehension of modern infrastructure as code and misconfigurations with little thought for container security and API security
- Lack of visibility and context into the code and the build itself with Security teams not often involved in build process and controls
- Compliance: Difficult to apply/administer policies across multiple CI and security tools
While traditional tools fall short, the importance of software supply chain security is in the spotlight, even as a point of national security. It is anticipated that the US government will release additional guidelines for software used by government agencies. In addition, NIST's DevSecOps project is working to create a set of DevSecOps practices explaining that "DevSecOps helps ensure that security is addressed as part of all DevOps practices by integrating security practices and automatically generating security and compliance artifacts throughout the process." Similarly, the Cloud Native Computing Foundation (CNCF) has drafted recommended best practices for DevSecOps. Together, these guidelines will provide a starting point and a way to identify the most critical efforts for compliance.
The role of a DevOps Platform
As one of the only true end-to-end DevOps platforms, GitLab has a role to play. GitLab can help you meet the challenges of developing modern applications while enabling a higher level of security. GitLab is a recognized leader in both SCM and CI, and more recently, an up-and-comer in the application security space. GitLab has built security features right into the DevOps platform (DevSecOps anyone?), and industry analysts have included GitLab in a wide variety of reports where the GitLab's security features are compared head-to-head against point security solutions.
An integrated platform like GitLab brings benefits that individual tools cannot, including things like:
- End-to-end visibility and auditability: Who changed what, where, and when.
- Consistent application and administration of policies: Both what policies are used where, and the actions taken for exceptions
- More intelligent response through greater end-to-end context
- Reduced attack surface of a simplified toolchain
Five steps to greater application security
With an estimated 30 million+ users from startups to global enterprises, GitLab has to take security seriously. Here are five ways to combine our powerful DevSecOps platform with a holistic security program to help you quickly gain control and visibility of your software supply chain. These efforts will require a combination of people, processes and tools, along with cross-department collaboration.
Step 1: ASSESS your security hygiene, considering new attack surfaces
Even the most damaging attacks tend to rely on complacency toward basic security hygiene (think patches and passwords) and use tried and true exploits that have been around for a long time. While this recommendation may not be anything new, the scope of the effort may be. Revisit your security policies, and consider new attack surfaces such as your software development toolchains, containers, orchestrators, and infrastructure as code. Are secrets detected? Is multi-factor authentication used? Check your admin settings for visibility and access controls.
Step 2: AUTOMATE scanning, policies, and compliance
Do you automate security scans within standardized CI pipelines? Most people use SAST and/or penetration testing and more are adding dependency scanning. Each type of scan will find different types of vulnerabilities, but applying comprehensive scans to your entire application portfolio can be prohibitively expensive with point solutions. If you try to integrate multiple scan types into a heterogeneous tool chain, the complexity and cost is compounded.
GitLab's single platform includes comprehensive app sec scanning with SAST, DAST, dependency, container scanning, secrets detection, and fuzz testing including API fuzzing. That allows you to do three things:
- Scan all of your code, including third party code and code in containers. You can easily configure security scans used via GitLab Ultimate's AutoDevOps feature.
- Scan every code change. GitLab's built-in app sec testing scans every code change using multiple scan methods with one common UI. Even DAST can be run within the CI pipeline by leveraging the review app (within GitLab's CI capability). Because scans occur before the code is pushed into a main branch, it's possible to introduce fewer vulnerabilities into shared environments.
- Utilize Fuzz Testing to find insecure logic flaws that do not have a signature of a known CVE. GitLab's security scanning includes both coverage-guided and behavioral testing for web APIs. Because fuzz testing is integrated into the CI pipeline alongside the other scanners, the results are more readily available and set up is easier than stand-alone fuzzing.
Automation is great, but you also must ensure that it is applied in a standardized, controlled CI process. As CNCF points out, "Automating as much of the software supply chain as possible can significantly reduce the possibility of human error and configuration drift." Do you require a standardized CI template to be used for all projects? Do you automatically apply compliance to an industry standard? When vulnerabilities are found, who can approve MRs with policy exceptions?
Automating policies ensures more consistent compliance while also reducing the audit surface. The automation of CI/CD is one vehicle to apply common controlsthat include things like:
- Segregation of incompatible duties
- Identity and access approval controls
- Configuration management and change control
- Access restrictions for changes to configurations and pipelines
- Protected branches and environments
- Auditing
- Licensed code usage
- Security testing
GitLab Ultimate offers many compliance capabilities within a single DevOps platform. Included are a compliance dashboard along with a host of compliance features, compliance management, and audit reports. In short, apply automation wherever possible to make it more likely that policies are applied consistently.
Step 3: PROTECT the application's infrastructure
Modern applications rely on much more than the code itself. You have to consider your cloud-native infrastructure like Docker and Kubernetes environments. Apply container scanning and use SAST to scan Helm charts. Consider using GitLab Container Host Security and Container Network Security. GitLab's integration with Falco and AppArmor, when used in the CI environment, can alert and prevent build servers from doing unexpected things such as modifying scheduled tasks (OS configuration in general). Check more obscure things like the container registry. Who at your org has write access? A compromise of one person could potentially lead to a compromise of the container registry, which could lead (via pipelines) to compromises of numerous projects.
Step 4: SECURE the software factory itself
GitLab's DevOps platform simplifies the effort required to secure the software factory itself with one place to manage access, software factory policies, and repeatable, measurable processes. GitLab's Security team has several blog articles on best practices and projects that may be helpful:
- Applying Zero Trust principles (things like least privilege access). Even one of our vendors took notice: GitLab Goes All In on Zero Trust to Secure a Fully Remote...
- Our continued integration of new technology has an emphasis on both productivity and security. For instance, our integration with Hashicorp Vault can require all entities operating in the supply chain environment to mutually authenticate using hardened authentication mechanisms with regular key rotation.
- Consider hardening the GitLab instance. These best practices are a place to start while additional research is being done openly to help improve the product and further enhance the hardening process. Hardened UBI-based cloud native GitLab images should be checked and verified regularly.
- CI/CD Variables can control the behavior of pipelines. Scoped environments can limit the scope of a CI/CD variable by defining for which environments it can be available (production, for instance).
Step 5: ITERATE with continuous assessment and improvement
Securing the modern software supply chain will require you to revisit steps 1-4 above continuously. The more complex your toolchain or environment, the harder it is to stay current on securing your app and your supply chain. Modern application development processes demand a new way of thinking, tooling the software factory itself for security and controls, rather than inspecting code after it's built. This mindset can be challenging, especially when you are saddled with expensive, traditional tools.
GitLab's DevOps platform with built-in security features makes this continuous improvement possible, but there are certainly no guarantees when it comes to security. If a nation state or individual is persistent enough with a very targeted attack, such as the one against Solarwinds, even the best defenses may be susceptible to malice. Neither GitLab, nor any other vendor, can claim to be able to protect customers from these attacks alone. A Defense-in-Depth strategy is always best and the simplicity of a single DevSecOps platform like GitLab is a powerful security enabler that can simplify your efforts and improve your visibility and control points.
