DevSecOps Days - Pittsburgh

Welcome to DevSecOps Days Pittsburgh 2022!

DevSecOps is a term and pursuit that has been underway for several years now. Despite that reality, there is still much to be desired with industry adoption and maturity. This talk will take a look at some of the areas of improvement in terms of technologies and practices that can help facilitate the desired outcomes of DevSecOps while also highlighting some of the remaining challenges.

Take a short break, but be sure you're back in time for the next presentation!

CyberSecurity has traditionally been regarded as a function of a distinct security group. In reality, security and cyber resilient software is the responsibility of everyone in the organization. There is a well intended call to "shift security left" but no one knows how! Instead, organizations are depending on developers to become cyber-savvy on their own. Attendees will learn about why to *not* shift left, how to build a new security culture, and tips, tricks, and tools for moving away from security hobbyists to having experienced pros.

Take a short break, but be sure you're back in time for the next presentation!

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.

Take a short break, but be sure you're back in time for the next presentation!

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.

Get some lunch, take a little break, and join us in time for our afternoon keynote!

Creating a baseline and tracking metrics are required to improve the flow of delivery. The most common questions, when organizations begin, are "How can we measure CD? What metrics matter?" However, why are we measuring? What are our goals? In this talk, we'll be discussing some common metric anti-patterns. We'll also cover some examples of how to use metrics constructively to identify where improvement efforts should be applied and how to scale that knowledge across the organization.

Take a short break, but be sure you're back in time for the next presentation!

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.

Take a short break, but be sure you're back in time for the next presentation!

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.

Take a short break, but be sure you're back in time for the next presentation!

Welcome to DevSecOps Days Pittsburgh 2022!