DevSecOps Days - Pittsburgh

The adoption of open-source software continues to grow and creates significant security concerns for everything from software supply chain attacks in language ecosystem registries to cloud-native application security concerns. In this session, we will explore how developers are targeted as a vehicle for malware distribution, how immensely we depend on open-source maintainers to release timely security fixes, and how the race to the cloud creates new security concerns for developers to cope with, as computing resources turn into infrastructure as code.

Building DevSecOps programs can be boosted and matured through using Chaos Engineering practices, but within a security context. This talk will introduce the concept of Chaos Security Engineering, why it will be useful in maturing DevSecOps program, and helpful resources and tools for starting your own program. This talk will also highlight the importance of the hypothesis mode of testing, which can also be seen in ethical hacking practices. The idea is to combine two separate ideas which have similar methodologies, to help integrate ongoing security testing throughout development cycles.

In a highly regulated environment, container images are built by a pipeline that enforces a variety of constraints, for example, to use the latest version of software dependencies. Existing tools can update top-level dependencies but stop short of updating entire dependency trees. A more complete solution would also update sub-dependencies required during a build. Our solution and the subject of this talk, uses a 'dependency pipeline'. More specifically, this is a series of automation steps which download and neatly package our container image’s dependencies, preparing them for installation in the pipeline of a given highly regulated environment. Using our dependency automations have cut the maintenance times of our developers from hours of effort each week to mere minutes. Additional key benefits of our solution are dependency version conflict avoidance and immediate CVE resolution. A Linux container (LXC) is typically composed of a set of files from custom software builds, downloaded dependencies, and common OS-specific files that are bundled together to deliver some reproducible functionality. Many of these files likely originate from open-source software repositories. Highly regulated environments pose stringent constraints on the functionality of active systems within their bounds such as disallowing the downloading of files from the open Internet. A common requirement for container builds in highly regulated environments is the use of dependencies that are locally stored or downloaded from the open internet using pre-approved package managers and repositories, which typically only contain a small subset of a container build’s needed dependencies. Successful container builds in this environment, are commonly obligated to use a list of required dependencies, which are not available in pre-approved repositories. The list includes for each dependency: a filename, hash value of the file, and an open internet download URL. During the build process, the list of files is downloaded from the provided URLs and placed into a clean local storage build context, within the highly regulated environment, and hash values are generated and compared to ensure file integrity. The validated files are then made available for container builds. Once built, the container enters a long-term maintenance lifecycle phase. In this phase, individual dependency updates are performed to resolve detected CVEs and CCEs, build errors, new version releases, etc... These updates, which are normally done by manually updating individual dependency entries in the required dependencies list, can cause version conflicts. This often occurs with the version update of a single dependency which contains sub-dependencies requiring the older version, or a deprecation of required functionality from the new version. The result is a build failure of unable to locate a compatible version. The current remedy is the non-trivial task of manually identifying and updating versions of multiple individual entries in the required dependencies list which often creates a high volume of cyclical sub-dependency version conflicts requiring hours of effort to analyze and mitigate. Our solution, as described above, resolve these issues.

Many engineering teams view DevSecOps initiatives from the perspective of being more secure from external threats/vulnerabilities. As a result, they focus more on the security aspect, rather than the architectural / engineering aspect.

In this talk, I try to focus on DevSecOps from the architecture perspective. I try to link DevSecOps with the common pillars of a Cloud based well-architected framework, and discuss how DevSecOps goes a step further from security, and delves into architectural practices .

Security is always there at the core, but the practices and patterns enforced by DevSecOps can be adopted/extended on a much wider scale, if we also factor in the engineering excellence, or architectural best practices that can be infused into the system as a direct consequence/correlation of adopting DevSecOps.

The idea of this talk is for audience to be able to link Architecture Best practices with DevSecOps initiatives, instead of just security.

Implementing DevSecOps without architectural best practices in mind, might not fail, but will surely be regarded as a missed chance to significantly improve the engineering discipline across an enterprise.