In this session, we'll explore DevSecOps in terms of these assertions about where we currently are and where we need to be:
Where we are: Users download packages and use simple checksum digests and commonly depend on security scanners on the final products (e.g., container, binary) before they're deployed into production. It's a less-than-optimal feedback loop for the developer, as any insight into a security threat would already have been introduced into the build pipeline after their code commits. DevSecOps is a means to inject security into every step of development so that developers get early feedback, and security risks are nullified before entering later into the build flow. Provenance verification of modules is not always easy, because few registries provide a trustable hashing service coupled with a cryptographic signing system alongside the package repository service itself. All these topics apply to software developers in well-known ecosystems like Python or Java. It also affects data scientists and even the reproducibility and predictability of AI applications.
Where we’d like or need to be: The entire software build pipeline requires a complete chain of cryptographic-based attestation and non-repudiation of all artifacts committed and generated by the various actors within the supply chain. We also need to harness machine learning and AI to assist developers gain early insight into attacks introduced to their software from compromised upstream packages, security coding flaws and other risks commonly associated with software build processes and development.
Join Marizol Martinez, Principal Technical Project Manager, Red Hat, Christoph Goern, Software Engineering Manager, AI Center of Excellence, Red Hat, Luke Hinds, Security Engineering Lead, Emerging Technologies, Office of the CTO, Red Hat for this discussion.