DoD Enterprise DevSecOps Initiative Overview
DoD Enterprise DevSecOps Initiative Overview
Air Force
Integrity - Service - Excellence
v4.51 – UNCLASSIFIED
Problem Statement
◼ What is DevSecOps?
◼ The software automated tools, services, and standards that enable programs to develop, secure, deploy, and
operate applications in a secure, flexible and interoperable fashion.
◼ Why should I care?
◼ Software and cybersecurity pervades all aspects of DoD's mission (from business systems to weapons systems
to Artificial Intelligence to cybersecurity to space) - establishing DevSecOps capabilities will:
◼ Deliver applications rapidly and in a secure manner, increasing the warfighters competitive advantage
◼ Bake-in and enforce cybersecurity functions and policy from inception through operations
◼ Enhance enterprise visibility of development activities and reduce accreditation timelines
◼ Ensure seamless application portability across enterprise, Cloud and disconnected, intermittent and
classified environments
◼ Drive DoD transformation to Agile and Lean Software Development and Delivery
◼ Leveraging industry acquisition best practices combined with centralized contract vehicle for DevSecOps tools
and services will enable rapid prototyping, real-time deployments and scalability.
◼ We cannot be left behind: China, Russia and North Korea are already massively implementing DevOps.
◼ Enables any DoD Program across DoD Services deploy a DoD hardened Software Factory, on their
existing or new environments (including classified, disconnected and Clouds), within days instead of a
year. Tremendous cost and time savings.
◼ Multiple DevSecOps pipelines are available with various options (no one-size-fits-all)
◼ Enables rapid prototyping (in days and not months or years) for any Business, C4ISR and Weapons
system. Deployment in PRODUCTION!
◼ Enables learning and continuous feedback from actual end-users (warfighters).
◼ Enables bug and security fixes in minutes instead of weeks/months.
◼ Enables automated testing and security.
◼ Enables continuous Authorization to Operate (c-ATO) process. Authorize ONCE, use MANY times!
◼ Brings a holistic and baked-in cybersecurity stack, gaining complete visibility of all assets, software
security state and infrastructure as code.
YOU
Application
Development Teams can build
software/microservices leveraging Layer
Leverages the Sidecar Container Security Stack
hardened containers
Service Mesh
Brings baked-in security and Layer
Continuous Monitoring
Platform
Continuous Integration /
One
Continuous Delivery
Fully containerized, leverages DoD approved containers from DCAR
Development Team selects tools from 172 approved containers or custom
(CI/CD) Layer
containers
Platform
CNCF compliant Kubernetes (K8S) Layer
Includes Site Reliability Engineers (SREs) etc.
Development Team selects between approved K8S stacks
Cloud
One
Infrastructure
Layer
BUILD
“Continuous
Integration &
Continuous
Delivery” MONITOR
TEST Orchestration
SECURE
Container and Container
Management
SCALE
STORE ARTIFACTS
DoD Enterprise DevSecOps Architecture*
Centralized DoD
Enterprise DevSecOps
Application / Microservices Artifacts Repository
Program pulls
built by DoD Programs.
Source code pulls Continuously
Hardens Docker Public
repository DoD Enterprise DevSecOps Platform** Artifacts
pulls Images and Assesses Open
(ISTIO)
Sidecar DoD OCIO/DISA
DevSecOps
Container Centralized
CI/CD Security
pulls
pipeline** Fluentd Real- Logs/Telemetry****
Stack time pushes
Elasticsearch
pulls
Kubernetes Per DoD Service for
Service-wide Visibility
*each DoD Program can have its own instantiation Optional Abstraction Layer with
of the DoD Enterprise DevSecOps Platform on any
Logs/Telemetry****
Red Hat OpenShift or PKS or CNCF
Cloud. compliant Kubernetes Product
** can be installed with single command and
deployed on any Cloud.
*** could be deployed inside an enclave or on- Bare-metal, GovCloud, AWS Secret, Azure Secret,
premises mil Cloud, C2S, Jedi…***
**** gives complete visibilities of assets,
security/vulnerability state etc. can be integrated to
existing cybersecurity shared services.
13
Microservices Architecture (ISTIO)
◼ Turnkey Service Mesh (ISTIO) architecture
◼ ISTIO side car proxy, baked-in security, with
visibility across containers, by default, without
any developer interaction or code change
◼ Benefits:
◼ API Management, service discovery,
authentication…
◼ Dynamic request routing for A/B testing,
gradual rollouts, canary releases,
resilience, observability, retries, circuit
breakers and fault injection
◼ Layer 7 Load balancing
◼ Zero Trust model: East/West Traffic
Whitelisting, ACL, RBAC…
◼ TLS encryption by default, Key
management, signing…
SSO
Keycloak
◼ Recommended Books
◼ A Seat at the Table – by Mark Schwartz (former CIO of USCIS, leader in Agile)
This book is highly recommended for ALL leadership as it is not technical but focused on the
challenges around business, procurement and how leadership can enable DevOps across
the organization and remove impediments.
◼ The Phoenix Project – by the founders of DevOps
◼ The DevOps Handbook – by Gene Kim, Patrick Debois.
For those who drive to work like me (for hours), please note that these books are available as
Audiobooks.
Chief Software Officer ◼ With 19 years of international tech, entrepreneurial and management
experience, Chaillan is the founder of more than 12 companies,
including [Link], Prevent-Breach, [Link], and
more.
◼ Over the last eight years alone, he has created and sold over 180
innovative software products to 40 Fortune 500 companies.
◼ Chaillan is recognized as a pioneer of the computer language PHP.
◼ Incentivize the use of Containers whenever possible to allow for scale and rapid deployment to any
Cloud or on premise servers.
◼ Incentivize the use of Container Management solution (Kubernetes) whenever possible to allow for
rapid deployment, side-car container security and rolling updates.
◼ Leadership can enable the adoption of DevSecOps by bringing its ENTIRE stack as a platform and by
leveraging DevSecOps solutions.
◼ It is imperative not to “select” a limited option of tools. The key of microservices and containers is to be able
to use the best solution to achieve the outcome desired. We should not limit options to the extend possible.
◼ Need to establish baseline requirements / thresholds for cybersecurity, test coverage, test results,
documentation. This shouldn’t be reinvented per office but global to DoD as a standard practice to facilitate
adoption.
◼ Once those baseline requirements are set, OCIO can provide CI/CD Platform’ stack with embedded security
as a side-car container and provide pre-ATOs for systems using the Platform stack and automatically
integrating the OCIO security baseline requirements.
◼ Bringing the entire stack as a Platform as a Service is key to avoid that each office reinvents the wheel and
builds their own baseline requirements.
◼ Understand that Failing is a GOOD thing! It is part of learning. It allows us to understand what works and
what doesn’t - AS LONG AS we leverage rapid prototyping, which allows for QUICK failure and mostly
painless. It also allows us to reprioritize rapidly and leverage learnings.
◼ Most people treat IT as a contractor/vendor relationship that provides IT services and most don’t
trust that IT developers can/want to deliver on-time and efficiently. As long as we treat IT as a
vendor, this relationship is bound to fail.
◼ Thanks to DevOps and Agile, we can continuously monitor everything. There is no need for
phases and milestones, we can continuously check the status of the Product Backlog and the
continuously delivered product in testing/staging environment or even in production.
◼ We can immediately verify that our assumptions are correct and learn faster.
◼ This provides BETTER and more TANGIBLE and qualified monitoring as we can leverage metrics
and real-life feedback.
◼ Thanks to Agile and DevSecOps principles, we collect real-time telemetry to gain continuous
visibility on our deployments.
◼ Mandating the use of containers and Kubernetes whenever possible will enable us to gain
complete visibility of the container’s stack, thanks to the use of side-car containers.
◼ A side-car container runs along side of all container pods, ensuring that no matter the size of the
clusters, a security container will be present to get visibility, enforce security best practices and
compliance requirements.
◼ By leveraging Agile methodologies, integrating new DevSecOps pipeline solutions and defining
a security baseline per product to ensure proper compliance and security.
◼ Each new product in the stack will be containerized in a Hardened Docker base image to enable
any development team to reuse it without having to reinventing the wheel (similar to the gold
images concept except this is using modern container technology).
◼ The waterfall model is a relatively linear sequential design approach for certain areas
of engineering design. In software development, it tends to be among the less iterative and
flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall)
through the phases of conception,
initiation, analysis, design, construction, testing, deployment and maintenance.
◼ The waterfall development model originated in the manufacturing and construction industries;
where the highly structured physical environments meant that design changes became
prohibitively expensive much sooner in the development process. When first adopted for
software development, there were no recognized alternatives for knowledge-based creative
work.
◼ Waterfall basically is a sequential model where software development is segregated into a
sequence of pre -defined phases – including feasibility, planning, design, build, test, production,
and support. On the other hand, Agile development methodology follows a linear sequential
approach while providing flexibility for changing project requirements, as they occur.
◼ Agile software development describes an approach to software development under which requirements and
solutions evolve through the collaborative effort of self-organizing and cross-functional teams and
their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery,
and continual improvement, and it encourages rapid and flexible response to change.
◼ The term agile (sometimes written Agile) was popularized, in this context, by the Manifesto for Agile
Software Development. The values and principles espoused in this manifesto were derived from and
underpin a broad range of software development frameworks, including Scrum and Kanban.
◼ There is significant evidence that adopting agile practices and values improves the agility of software
professionals, teams and organizations;
◼ Agile enables you to learn directly for end users and implement changes while doing so.
◼ Extreme programming (XP) is a software development methodology which improves software quality and
responsiveness to changing customer requirements. It advocates frequent "releases" in short development
cycles, which is intended to improve productivity and introduce checkpoints at which new customer
requirements can be adopted. It includes: programming in pairs or doing extensive code review, unit
testing of all code, avoiding programming of features until they are needed, flat management structure, code
simplicity and clarity, expecting changes in the requirements as time passes and the problem is better
understood, and frequent communication with the customer and among programmers.
◼ Scrum Sprint is a repeatable fixed time-box during which a "Done" product of the
highest possible value is created. It also has a maximum duration. Usually, a Sprint
lasts for one month or less.
◼ Usually, daily meetings are held to discuss the progress of the project undertaken and
any difficulty faced by any team member of the team while implementing the project.
The outcome of the sprint is a deliverable, albeit with some increments. The scrum is
used for projects like Web Technology or development of a product for the new
market, i.e. the product with lots of requirement or fast-changing requirement.
User stories are one of the primary development artifacts for Scrum and Extreme
Programming (XP) project teams. A user story is a very high-level definition of a
requirement, containing just enough information so that the developers can produce a
reasonable estimate of the effort to implement it.
Product Owner is responsible for product's current state of development and for
maximizing the product's value. Product Owner can be one person, even if he represents
a committee. His jobs includes:
◼ Maintaining items in Product Backlog.
◼ Assigning order to items in Backlog.
◼ Ensuring that items in Product Backlog are clear to the Development Team.
It is important to ensure that the product owners include end users that understand the
end goals for the product.
The product backlog comprises an ordered list of product requirements that a scrum
team maintains for a product. The format of product backlog items varies, common
formats include user stories, use cases, or any other requirements format the team finds
useful. These will define features, bug fixes, non-functional requirements, etc.—whatever
must be done to successfully deliver a viable product. The product owner prioritizes
product backlog items (PBIs) based on considerations such as risk, business value,
dependencies, size, and date needed.
[Link]
◼ Development Team
The development team is responsible for the implementation of the articles in Sprint
Backlog . Although several members of the development team may specialize in different
areas, the development team as a whole is responsible for the development of
functionality.
◼ Sprint Backlog
Sprint Backlog refers to a subset of Product Backlog that is selected for a Sprint along
with its delivery plan. Based on the items in the Sprint Backlog, Development Team
decides how they will create a "Done" product.
◼ Daily Scrum
◼ Daily Scrum is a fixed time, fixed place event that allows Development Team to synchronize
and plan work for the next 24 hours based on the amount of work done since the last Daily
Scrum. During Daily Scrum, Development Team members explain:
◼ What did I do yesterday that helped towards Sprint Goal?
◼ What am I going to do today towards my Sprint Goal?
◼ What Impediments I see towards accomplishing my Sprint Goal?
◼ Daily Scrum usually lasts for 15 minutes, but can be followed by other meetings for detailed
discussions.
◼ Sprint Review & Retrospective
◼ Sprint Review is scheduled after the sprint ends to inspect the amount of work done and
adapt the Product Backlog if necessary. Similarly, Retrospective is used to analyze what
went right in the Sprint and what could be improved upon. This Retrospective feedback
helps improve the process in Sprints to follow.
5. All the project development phases such as designing, development, testing, etc. are
completed once in the Waterfall model while as part of the Agile methodology, they follow an
iterative development approach. As a result, planning, development, prototyping and other
software development phases can appear more than once during the entire SDLC
6. One of the major differences between Agile and Waterfall development methodology is their
individual approach towards quality and testing. In the Waterfall model, the “Testing” phase
comes after the “Build” phase, but, in the Agile methodology, testing is typically performed
concurrently with programming or at least in the same iteration as programming
7. While Waterfall methodology is an internal process and does not require the participation of
customers, the Agile software development approach focuses on customer satisfaction and
thus, involves the participation of customers throughout the development phase.
8. The Waterfall model can be regarded as a stringently sequential process, however, the Agile
methodology is a highly collaborative software development process, thereby leading to better
team input and faster problem solving
9. The Waterfall model is best suited for projects which have clearly defined requirements and in
which change is not expected at all, while Agile development supports a process in which the
requirements are expected to change and evolve. Thus, if you are planning to develop a
software that would require frequent overhauls and has to keep up with the technology
landscape and customer requirements, Agile is the best approach to follow
10. The Waterfall model exhibits a project mindset and lays its focus strictly on the completion of
project development, while Agile introduces a product mindset that focuses on ensuring that
the developed product satisfies its end customers, and changes itself as the requisites of
customers change
◼ DevOps is a software engineering culture and practice that aims at unifying software
development (Dev) and software operation (Ops). The main characteristic of the
DevOps movement is to strongly advocate automation and monitoring at all steps
of software construction, from integration, testing, releasing to deployment
and infrastructure management. DevOps aims at shorter development
cycles, increased deployment frequency, and more dependable releases, in close
alignment with business objectives.
◼ DevOps is NOT ENOUGH! DevSecOps is what must be implemented with the
cybersecurity stack built-in into the DevOps pipeline.
Continuous Integration and Continuous Delivery are key parts of the DevOps pipeline.
◼ Continuous integration (CI) is the practice of consolidating all new source code into a
shared version control server such as GitHub, several times a day.
◼ Continuous delivery (CD) is used to deliver (release) software in short cycles, ensuring
that the software can be reliably released at any time. It aims at building, testing, and
releasing software with complete automation. The approach helps reduce the cost,
time, and risk of delivering changes by allowing for more incremental updates to
applications in production. A straightforward and repeatable deployment process is
important for continuous delivery.
◼ Extreme programming (XP) adopted the concept of CI and did advocate integrating
more than once per day – perhaps as many as tens of times per day.
DevSecOps is the next evolution of agile and builds on the agile principles by adding the
following:
◼ Leverages Containers and Microservices concepts.
◼ Leverages Cloud deployment for scalability and prototyping.
◼ Continuous Integration/Continuous Delivery to rapidly prototype, test and deploy.
◼ Leverage A/B testing and canary deployment for rapid feedback loops.
◼ Embed security in the pipeline instead of an after-thought.
Automated testing is a key part of DevSecOps. It is enabled by multiple tools that measure both
test code coverage and test results. They are fully automated and do not require human action.
It also enables new concepts like pair programming and peer code review.
Agile brings several new models for creating the right tests:
Test-driven development (TDD) is a software development process that relies on very short
development cycles: requirements are turned into very specific test cases first, then the software is
built to pass the tests.
Acceptance test–driven development (ATDD) is a development methodology based on
communication between the business customers, the developers, and the testers. ATDD
encompasses many of the same practices as specification by example, behavior-driven
development (BDD), example-driven development (EDD), and support-driven development also
called story test–driven development (SDD). All these processes aid developers and testers in
understanding the customer's needs prior to implementation and allow customers to be able to
converse in their own domain language.
◼ Allows for the deployment of complex applications (ie. Multiple microservices) with a
single command.
◼ Allows for rolling updates and rollbacks with no downtime.
◼ Deploys security stack as a side-car container to gain complete visibility, including
security posture, MFA enforcement, identity management, logging etc.
◼ Auto-scaling – allows to provision resources dynamically based on use and
maximums, saving significant Cloud computing costs
◼ Restarts containers seamlessly and automatically in case of crash or other issue.
Helm helps you manage Kubernetes applications — Helm Charts helps you define,
install, and upgrade even the most complex Kubernetes application.
Charts are easy to create, version, share, and publish — so start using Helm and stop the
copy-and-paste madness.
The latest version of Helm is maintained by the CNCF - in collaboration with Microsoft,
Google, Bitnami and the Helm contributor community.
◼ Enable the creation of packages for easy deployment of complex container/Kubernetes
based solutions.
◼ Allows for versioning, rolling-update and rollbacks.
◼ Allows for rapid experimentation and uncertainty while focusing on mission end goals.
◼ Enable rapid prototyping and A/B testing or canary releases.
◼ New services and innovations are made available
◼ Frequency of deployments is increased
◼ Collaboration between various department is increased
◼ Time spent maintaining applications and fixing is greatly reduced
◼ Number of end users who are using organizations’ services is increased
◼ Performance and quality of applications is improved
◼ Time-to-market is reduced
◼ Time needed for testing, development and operations is reduced.
◼ Mean-time to recovery: shows how long it would take applications in the production
stage to recover from failure
◼ Mean-time to production: show how long it takes when new code is committed into
code repository
◼ Average lead-time: shows how long it would take for a new requirement to be delivered
and deployed
◼ Deployment speed: shows how fast you can deploy a new version of the application
between staging, test and production
◼ Deployment frequency: shows how often you can deploy a new release into production
environment and testing / QA.
◼ Production failure rate: shows how often software fails during production
1. Culture
Solution: Organizations should focus on building a collaborative culture with shared goals. This also includes
finding employees who are DevOps champions in the organization.
2. Test automation
Solution: Many organizations neglect test automation while focusing on CI/CD deployments. Continuous
testing is key for DevOps success, and security must be considered from the outset.
3. Legacy systems
Solution: Include modeling for legacy infrastructure and applications in your DevOps plans. Installing new
hardware or software to coexist with older systems is always difficult.
4. App complexity
Solution: Consider application architecture changes based on on-premises, cloud, and containers early on in
the process.
5. No DevOps plan
Solution: Create a clear plan that includes milestones, project owners, and well-defined deliverables.
6. Managing environments
Solution: Your organization can standardize and automate complex DevOps environments with cloud
sandboxes and other tools.
7. Skillset
Solution: Teams need training on DevOps. Organizations should standardized processes and establish
common operational procedures.
8. Budget
Solution: Remember that opensource does not mean free, and factor in integration and operational complexity
in your costs.
9. Tools
Solution: Avoid fragmented toolset adoption, which can add to your costs.
10. Leadership support
Solution: Educate leadership about the benefits of DevOps, in order to gain resource and budget support.
◼ Recommended Books
◼ A Seat at the Table – by Mark Schwartz (former CIO of USCIS, leader in Agile)
This book is highly recommended for ALL leadership as it is not technical but
focused on the challenges around business, procurement and how leadership can
enable DevOps across the organization and remove impediments.
◼ The Phoenix Project – by the founders of DevOps
◼ The DevOps Handbook – by Gene Kim, Patrick Debois.
For those who drive to work like me (for hours), please note that these books are
available as Audiobooks.









