Enterprise DevSecOps Reference Design from the DoD CIO – A Summary Content referenced from: https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference %20Design%20v1.0_Public%20Release sForDefense/raw/master/Meetup/2019/2019-10%20DO4D%20- %20DevSecOps%20Reference%20Design.pdfContainerized Software Factory Reference DesignSoftware Factory using Cloud DevSecOps Services Sidecar Container

1. Application code & dependencies 2. Environment scripts & creation tools 3. DB scripts and reference data 4. Containers 5. Automated tests 6. Project artifacts – documentation, procedures, etc. Coined by Martin Fowler in 2004 ii. Strangler Application 1. Put existing functionality behind an API 2. New functionality implemented in new services with new architecture 3. Make calls to old system

Way: First, that we have locked ourselves into a frame of reference that is getting in our way as we try to become Agile. This frame of reference includes the notions of project, systems, application,

that could become an error and will likely trigger an alert 4. Error – error conditions such as API failures, internal issues 5. Fatal – forces a termination iv. Examples of potentially significant Use telemetry to measure outcomes iv. Etsy open-sourced their experimentation framework – Feature API e. INTEGRATE A/B TESTING INTO OUR FEATURE PLANNING i. Product owners should consider each feature

suite becomes the living documentation of the system specification and represent working examples of API use e. DESIGN FOR OPERATIONS THROUGH CODIFIED NON-FUNCTIONAL REQUIREMENTS i. Designing for fast changes through pair programming or code review 3. Instrument the repository to detect suspicious code (API calls from certain types of test code) 4. Ensure every CI process is in an isolated container 5