UNCLASSIFIED
20
Unclassified
feedback loops, a core tenet of virtually all modern process improvement methodologies.
This maximizes the opportunities for our organization to learn and improve.” - [The DevOps
Handbook].
3. Third Way: Continual Learning and Experimentation. “The Third Way enables the creation of
a generative, high-trust culture that supports a dynamic, disciplined, and scientific approach
to experimentation and risk-taking, facilitating the creation of organizational learning, both
from our successes and failures. Furthermore, by continually shortening and amplifying our
feedback loops, we create ever-safer systems of work and are better able to take risks and
perform experiments that help us learn faster than our competition and win in the
marketplace.” - [The DevOps Handbook].
Zero Trust in DevSecOps
The DevSecOps ecosystem that includes the software factory and the intrinsic blending across
development, security, and operational creates complexity. This complexity has outstripped
legacy security methods predicated upon “bolt-on” cybersecurity tooling and perimeter
defenses. Zero Trust must be the target security model for cybersecurity adopted by
DevSecOps platforms and the teams that use those platforms.
There is no such as a singular product that delivers a zero trust architecture because zero trust
focuses on service protection, and data, and may be expended to include the complete set of
enterprise assets.
5
This means zero trust touches infrastructure components, virtual and cloud
environments, mobile devices, servers, end users, and literally every part of an information
technology ecosystem. To encompass all of these things, zero trust defines a series of
principles that when thoughtfully implemented and practiced with discipline prevent data
breaches and limit the internal lateral movement of a would-be attacker.
DevSecOps teams must consistently strive to bake in zero trust principles across each of the
eight phases of the DevSecOps SDLC, covered in the next section. Further, DevSecOps teams
must fully consider security from both the end user perspective and all non-person entities
(NPEs). To illustrate several of these concept in a notional list, these NPEs include servers, the
mutual transport layer security (mTLS) between well-defined services relying on FIPS compliant
cryptography, adoption of deny by default postures, and understanding how all traffic, both
north-south and east-west, is protected throughout the system’s architecture.
Behavior Monitoring in DevSecOps
The software factory platform and the DevSecOps team will quickly establish a normative set of
behaviors. To illustrate this point, a merge into the main branch should never occur without a
pull request that includes two or more additional engineers reviewing the code for quality,
purpose, and cybersecurity. There are two types of behavior monitoring that are required to
support the ideals of Zero Trust, covered above, and to enhance the overall cyber survivability
of the software factory platform, the software artifacts being produced within that factory, and
the different environments linked to the software factory: Behavior Detection and Behavior
Prevention. The idea of detection is to trigger an actionable and logged alert, possibly delivered
through a ChatOps channel to the entire team that conveys I saw something anomalous. The
idea of prevention goes a step further. It still triggers an actionable and logged alert, but it also
either proactively prevents or immediately terminates anomalous behaviors and conveys I
inhibited something anomalous. There are a multitude of technologies available to achieve