Sergey Nivens - Fotolia
Build up a DevSecOps pipeline for fast and safe code delivery
It's all well and good to automate the software build process, but without proper security practices in place, the DevOps pipeline can lead developers to deploy compromised code.
While ship at any cost is a well-known mantra in many high-pressure development environments, it means teams often overlook security during the build process. It's not uncommon for developers to accidentally ship software with security flaws or, worse, viruses, which IT support must deal with on live servers.
There are tools that can help developers ensure code is free of any glaring and known vulnerabilities, but security isn't just a process -- it's also a mindset. A DevSecOps pipeline requires the right mix of tools and practices.
IT teams can set policies and implement steps to turn a DevOps build pipeline into a DevSecOps one, covering code and container image scans, repository restrictions, and conventional OS hardening and firewall implementation. In addition, access management for the CI/CD pipeline is critical to DevSecOps.
Tools for build security
Developers in need of a feature -- or simply in a rush -- might pull random Docker images that contain vulnerabilities from public internet repositories. Developers should always treat public container registries with extreme caution.
Registry platforms, such as Harbor or even a self-hosted private local registry for the company, offer tighter control over what users deploy within an environment, and also streamline versioning and management to ensure DevSecOps doesn't impede code velocity. Docker Hub also offers certified images, but always exercise vigilance to minimize risk.
Other tools ensure code builds don't ship with known vulnerabilities. For example, to prevent the release of software with vulnerable libraries, the auditing tool Open Security Content Automation Protocol (OpenSCAP) scans systems in the delivery pipeline and checks them against the Common Vulnerabilities and Exposures (CVE) library. There are several CVE feeds, both free and paid, that OpenSCAP can use. The paid version offers access to additional features and reporting options beyond the free option.
There is also a version of OpenSCAP that can scan Docker images for vulnerabilities, a feature also found in tools such as Dagda and Layered Insight. The Docker Trusted Registry scans container images against known vulnerabilities, as well. The scans validate that builds are secure before they are released, which eliminates low-level risks in the software build process.
As a command-line tool, OpenSCAP can integrate with scripts or continuous integration tools, such as Jenkins, for automated software delivery in a DevSecOps pipeline. The tool executes a scan, and it returns a non-zero error code for failure results, which should stop the build and enable the developer to rectify the vulnerable library. Depending on how the developer chooses to react to the error level, OpenSCAP passes back an error code to the script execution platform.
Practice overall IT security
While developers assess the potential vulnerability in a build, the IT team should consider the quality of the overall platform. In addition to software code security, the team must ensure proper implementation of security within the OS, which includes a review of elevated permissions and rights on file systems. There should be no accounts with simple passwords -- or, worse, no password. Properly configured firewalls and hardening, which is the removal of unused services, provide additional security measures.
Know your customer
How exactly developers work security into the build process depends on an innocuous question: Who is the customer? Internal customers -- users who work for the company -- have different requirements compared to external customers, who access applications or programs from outside the company.
Depending on how the software product is delivered, internal customers can be somewhat more secure than external ones, as they already adhere to the company's security policies. Still, they aren't completely free of risk.
Adopt a DevSecOps mindset
Control access to CI/CD tools, as it only takes one bad actor to disrupt the pipeline. Audit your IT environment and use centralized authentication systems, such as Active Directory or the Lightweight Directory Access Protocol, to manage access. All good CI/CD pipeline tools should support integration with centralized authentication systems.
Most applications have to be signed in modern OSes to install. Maintain and secure those signing keys offline before releasing the official build. An attacker with a set of keys can do a lot of financial, operational and reputational damage.
Rather than implement all these security changes simultaneously, improve the DevSecOps pipeline over time. This incremental approach will reduce the risk of failure and prevent a huge influx of support calls.
All these DevSecOps tools and techniques can work together to provide an overarching security-minded posture. The pipeline architect, developers or automation specialist must test and evaluate these processes and tools, but once they're part of an automated pipeline, they can more or less function in the background, with appropriate maintenance and updates as needed.
