Software Acquisition

AAF  >  Software Acquisition  >  Enterprise Services and DevSecOps

Enterprise Services and DevSecOps

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

 

 

Reference Source: DODI 5000.87 Glossary

 

Enterprise Services are services that have the proper scope to play a productive role in automating business processes in enterprise computing, networking, and data services.  Enterprise services include technical services such as cloud infrastructure, software development pipeline platforms, common containers, virtual machines, monitoring tools, and test automation tools.  Responsibility for these functions is generally above the program manager.

 

Reference Source: DODI 5000.87 Section 1.2.h

 

Leveraging existing enterprise services, if available, is preferred over creating unique software services for individual programs.  These may be procured from the DoD, the DoD components, other government agencies, or commercial providers, and leverage category management solutions and enterprise software agreements.

 

Reference Source: DODI 5000.87 Section 3.3.b.(1)

 

Programs will assemble software architecture, infrastructure, services, pipelines, development and test platforms, and related resources from enterprise services and development contracts.  Leveraging existing services from enterprise services and development contracts will be preferred over acquiring new services to the extent consistent with the program acquisition strategy and IP strategy.

Enterprise Services and DevSecOps Guidance

Reference Source: USD(A&S) Guidance

“The team successfully developed, tested and deployed a critical software patch to the fleet in less than 60 days that provided an additional capability. 2 weeks to design/develop/test […]  Historically, a patch of this type would have taken greater than six months to get through the development, test, and deployment cycle.”

– Information Screening and Delivery System (ISDS) NDAA FY18 Sec. 873 Agile Pilot Program.

DevSecOps platforms should ideally be provided as an enterprise service with tailoring options as opposed to having each program independently develop separate instances of DevSecOps pipelines. An enterprise service is an enabling capability that can be leveraged by several software programs. Use of enterprise services provides some key benefits such as optimizing cost of platforms across the enterprise, leveraging skills across organizations, and minimizing complexity between toolsets. Considerations that a program should use in selecting an appropriate DevSecOps platform include:

  • Who (Service or Agency) is providing the DevSecOps platform?
  • Does the use of the proposed DevSecOps platform help the program achieve its desired software development value stream map?
  • What type of agreement (e.g., service level agreement) is in place to govern the use of DevSecOps solution?
  • Does the DevSecOps capability support collection and reporting of a minimum essential list of metrics?
  • Does the DevSecOps capability support the program’s roadmap?
  • What is the maturity level of the DevSecOps capability (i.e., is this capability being developed, already in use, widely used, etc.)?
  • Does the DevSecOps capability support the delivery model required by the application developer?
  • Are all the required tools and components already integrated into the DevSecOps pipeline?
  • Is the DevSecOps platform fully resourced?
  • Does this capability support the security requirements?
  • Are any key components missing from the DevSecOps service?
Security and Testing

Security and testing should be incorporated throughout the software development and delivery lifecycle. The selected DevSecOps pipeline should provide tools that support and integrate automated testing, security scans, logging, and monitoring.

Source Code Management Tools

Source Code Management (SCM) is an important feature of a DevSecOps pipeline. The use of tools that support source code management allows developers to check in code, leads to automated builds, and supports key security activities such as the ability to perform static checks.

Programs should create a designated Continuous Integration (CI) user account within the SCM tool, whose sole purpose is to interact with the CI server. This enables traceability from an access control perspective between SCM and CI services and avoids the need to enter individual user account credentials into the CI service.

Programs should have methods and tools to store source code that is delivered by a contractor. The delivery of the source code should be accompanied by the necessary tools required to manage the source code.

The complete software baseline should be interpreted as all configuration artifacts used throughout the development and delivery of software, beginning with the project MVP.  This is to include all configuration management criteria such as backlog tasks, user stories, epics task and time estimates. Baselines may also be split up into various categories along the SDLC such as:

  • Functional Baseline: initial specifications established; contract, etc.
  • Allocated Baseline: state of work products after requirements are approved Developmental Baseline: state of work products amid development
  • Product Baseline: contains the releasable contents of the project
  • Operational Baseline: state of deliveries/deployments and upon delivery/deployment of MVP into production
Continuous Integration

CI is one of the key objectives of DevSecOps. A best practice in many contexts is to build the CI application every time a check-in of code occurs. The build process should be automated, and while all tools are not equal in this regard, programs should make efforts to automate builds for their given technology set. When crafting a CI build plan, the goal should be to remain as agnostic as possible. Relying too heavily on built-in features of specific CI servers can lead to replication issues if the CI tool must be changed. The manual activity required to build a software package from code should be as minimal as possible; any necessary manual processes should be thoroughly documented and then replicated in a CI server.

Continuous Delivery / Continuous Deployment

Another key objective of DevSecOps is the ability to deliver a version of the software, once compiled, to an environment where it can be operated, outside the development environment. In commercial environments, the goal may be Continuous Deployment: once a new working version of the software has been compiled and shown to pass the appropriate quality checks it can be deployed directly into the operational environment for users. In the DoD context, it is often appropriate to focus on Continuous Delivery, in which each new working version of the software is delivered to another environment (e.g., an operationally relevant test environment) but not to operational users. This distinction is entirely appropriate to the DoD context. For example, in the case of weapon systems, the Warfighter may not be able to adopt frequent updates to operational systems given the need for similarly updated training and tactics. (Because of this distinction, this guide uses the more general term “Continuous Delivery” throughout.) Programs should ensure that they are making the correct choice concerning where to deliver operational software.

Even though Continuous Deployment may not be appropriate for many of the DoD’s use cases, the goal of automating as much as possible throughout the pipeline remains the same. A DevSecOps pipeline practicing Continuous Delivery should have enough automated testing in place so that, even though software will not be deployed directly to production, delivery could still be feasible due to the rigor of in-place automated testing. A common practice that makes this possible is to use of containerization to create testing environments on the fly, run automated tests, and then destroy the environment immediately after the tests have concluded. This can be accomplished as part of the Continuous Delivery or Deployment process. Because this short-lived test environment is created with every build, it allows continuous insight to determine whether or not Continuous Deployment could be a possibility, even if Continuous Delivery has been the chosen method of moving artifacts into production.

Additional decisions that programs should consider include:

  • Delivery Model – What delivery model will the program use? Examples include:
    • Model A: Continuous Delivery – automates delivery to persistent environments (either cloud or on-premises)
    • Model B: Cloud-Enabled Delivery – deploys applications automatically after provisioning a new environment from the cloud or data center. The primary difference from Model A is that Model B uses Infrastructure as Code.
    • Model C: Container-Enabled Delivery – deploys applications as a set of containers into one or more hosts that are dynamically created. The primary difference from Model B is that Model C involves full support of modular application architectures (e.g., micro-services).
  • Release Orchestration Tools– What release orchestration tools does the platform provide to support continuous delivery?
  • Container Tools – What container tools will the program use to support continuous deployment?
  • Release Cadence – How often will releases be deployed to various environments in accordance with the delivery model?
  • Release Scope – Will delivery take the form of full or incremental releases?
  • Transition – What are the DevSecOps implementation plan and plan to transition to the pipeline?
Continuous Learning Modules
Software Factories
Resources