20240215_TCODE PWS Draft-Track Change Add to Section 1.3 Scope.pdf

UNCLASSIFIED

Program Executive Office USTRANSCOM (PEO)

Performance Work Statement For

TRANSCOM Cloud Optimal DevSecOps Ecosystem

(TCODE)

23 January 2024

DRAFT Version 1

1 Description of Services

1.1 Background

DevSecOps is an organizational software engineering culture and practice that aims at unifying software developer (Dev), security (Sec), and operations (Ops). The main characteristic of DevSecOps is to improve customer outcomes and mission value by automating, monitoring, and applying security at all phases of the software lifecycle: plan, developer, build, test, release, deliver, deploy, operate, and monitor. Practicing DevSecOps provides measurable improvements for both quality and security. These improvements can be realized by faster deployment speed, higher deployment frequency, quicker requirement lead-time and mean-time to production, lower production failure rate and lower mean-time to recovery.

The TRANSCOM Cloud Optimal DevSecOps Ecosystem (TCODE) is a Platform as a Service capability with the goal to adopt the DoD Enterprise DevSecOps Platform Initiative (DSOP) in USTRANSCOM by leveraging lessons learned by the Platform One program, industry best practices, open-source software such as Kubernetes, and commercial solutions to instantiate DevSecOps continuous integration, delivery, and deployment pipelines at various classification levels.

1.2 Objective

TCODE is the convergence of development, security, and operations. It is an organizational mechanism that aims to adopt security from the beginning of the software development life cycle (SDLC) to the end. For most software applications in the past, security was added later in the life cycle, after development was completed. The advancements in cloud platforms, microservices, and containers enable the ability for security to keep up with rapid releases in an Agile development environment. DevSecOps integrates security with DevOps. Security becomes an integral, automated part of continuous integration (CI) and continuous delivery (CD) pipelines, and a responsibility shared by all stakeholders (platform team, Government auditors, and tenant application developers).

TCODE has three main goals:

• Support development teams—assist developers in applying secure coding practices.

Automated tools can notify stakeholders about security issues during all stages of development, to enable quick fixes and promote developer security education.

• Support security teams—enable easy monitoring and control over development projects without having to manually review and approve each release.

• Continuous security testing—detect security vulnerabilities as soon as they occur, minimize risk, and allow rapid remediation without slowing down the development pipeline.

USTRANSCOM has built a DevSecOps ecosystem for use by PEO programs (i.e., “tenants”).

The ecosystem utilizes infrastructure-agnostic platforms to support the DoD’s vast infrastructure options (including — Government clouds, on premise, disconnected and classified environments), with initial focus on AWS offerings from Cloud One. TCODE provides tenants the ability to leverage GitOps processes to deploy to a DevSecOps Kubernetes platform with hardened containers built from Iron Bank, to support the DoD’s ability to field operational capabilities faster.

TCODE is currently hosted in CloudOne AWS GovCloud and leverages PlatformOne services such as Big Bang, Iron Bank and Cloud Native Access Point as a Service. TCODE should be maintained and modified where applicable to implement evolving DOD mandatory standards and guidance. The objective is to implement the technologies and processes that will lead TCODE to achieving a continuous Authority to Operate as defined by the DOD CIO. The current TCODE architecture is depicted in Attachment X.

1.3 Scope

The Contractor shall maintain and modify (where applicable) existing software factory services for USTRANSCOM software developers, establish and maintain target platforms for software delivery across Impact Levels 2, 4, 5 and 6 (SIPRNET) as applicable to the tenant application requirements, create automated software deployment processes, and support PEO program migrations to TCODE, so legacy program software developers can leverage TCODE’s modernized ecosystem services. The Contractor shall coordinate all TCODE activities with the Government, Federally Funded Research & Development Centers (FFRDCs), and other DoD contractors to achieve these outcomes and realize the goals of the DSOP initiative for

USTRANSCOM.

The TCODE platform is expected to host a minimum of 14 tenant applications. The total number of unique end users across all tenant applications ranges between 10k and 100K. The Contractor shall support pipelines, onboarding, and sustainment for the tenants. The Contractor shall strategize tenant application onboarding and align onboarding with the team’s capacity and program’s roadmap. The TCODE environment currently has 8 Clusters running approximately 20 EC2s. The Contractor shall scale accordingly as tenants onboard and increase utilization of the platform. The EC2 instances that make up these clusters are fielded from a small number of templates and deployed using Infrastructure as Code (IAC). The Contractor shall maintain, develop, and/or add to these templates and associated IAC during the period of performance.

There is at least one pipeline per tenant. TCODE leverages AWS Cloud Service Offerings (CSO) to support the platform. TCODE only uses services that have a DOD provisional authorization for IL5 data/systems. AWS CSOs include, but are not limited to: VPC, EC2, EFS, RDS, EKS, S3, Glacier, SQS, Lambda, ElastiCache, Cloudwatch, Cloudtrail, IAM, KMS, Systems Manager, DynamoDB, Cloudformation, Certificate Manager, GuardDuty, Route53, Security Hub, Service Quotas.

The Contractor shall plan for and provide specialized systems, software engineering, sustainment, and production support services for USTRANSCOM, including current and emerging software capabilities. The Contractor shall provide ongoing Operations & Maintenance support to TCODE software factory services, and as requested by TCODE tenants in accordance with (IAW) the task areas in this Performance Work Statement.

Wilde, Georgia L CIV TRANSCOM TCAQ (USA) This section was updated today to add additional details under the Scope.

The Government may require surge support during the base or any option period. Surge modifications will be within the scope of the contract.

1.4 References

All references, including electronic libraries, can be found in Attachment 1_References.

2 Performance Requirements The Contractor shall use a TCODE Issue Tracking System (ITS) tool (e.g., Jira and Gitlab) to effectively manage and execute the Agile Scrum methodology to analyze requirements, decompose large requirements into logical sub artifacts, create user story level artifacts and technical specifications, coordinate with the appropriate subject matter experts (both technical and functional) to receive approved acceptance criteria for Epic/Task/Subtask level artifacts. The Contractor shall utilize the ITS to monitor the requirements management process.

The Contractor shall respond to ITS artifacts to change the system, as prioritized and assigned by the Government. The Contractor shall lead the Scrum process and other meetings to define, build, test, document, and deploy updates to the system baseline. The Contractor shall ensure lead-time for understanding and responding to unique change requests.

The planning for requested functionality may include the Contractor’s recommendations to minimize rework and cost. The Contractor shall work with subject matter experts to create, and receive approval on, user stories and associated acceptance criteria, functional specifications and/or technical specifications.

The Government and Contractor shall agree upon a set of artifacts to be delivered each sprint (the “Sprint Goal”) by working with the product owner(s) to ensure proper prioritization and readiness of the user stories. The objective is to ensure artifacts are delivered as planned against program milestones. The Government will assess the performance of the Sprint by evaluation the Contractor’s delivery into production against the Sprint Goal. The Contractor shall achieve and maintain delivery of 90% of sprint goal in each sprint and shall document sprint burndown in the Monthly Status Report (MSR).

2.1 Task Area 1: Provide Task Order Management

The Contractor shall provide the planning, direction, coordination, and control necessary to accomplish all requirements in this Performance Work Statement (PWS). The Contractor shall designate key personnel responsible for the cost, schedule, and technical performance for the contract and shall serve as a primary Point of Contact for both management and technical matters. The Contractor shall have a single point of contact between the Government and Contractor personnel to support business relations and fulfill the product manager role (i.e., a product manager is the person who manages and implements the customer requirements (Government/tenant applications) and the larger USTRANSCOM objectives that a product or feature will fulfill, articulates what success looks like for a product, and rallies a team to turn that vision into a reality). Coordinate and manage the overall service provided to a customer end-to-end. The product manager will monitor the costs for both the contract and platform hosting in the cloud environment to ensure that cost control is implemented, and no erroneous costs are incurred to the Government. The product manager will coordinate on a weekly basis with the Government team to ensure cost control is implemented. In the event the contractor has a misconfigured technical implementation and costs get out of control resulting in exacerbated costs, the contractor shall be responsible for acknowledging the misconfiguration, and working with the appropriate parties to recover the cost that was incurred due to the technical misconfiguration.

Scrum Ceremonies and Weekly Updates: The Contractor shall provide a detailed approach on how the Scrum teams will satisfy the requirements. The Contractor shall identify the Scrum Master(s) leading the Scrum team(s), and conducting scrum ceremonies (i.e. Sprint Planning, Daily Stand-ups, Sprint Reviews, Sprint Retrospectives, and Sprint Demos).

Additionally, the Contractor shall conduct Weekly Update Meetings between Government and Contractor Product Manager to: 1. Provide the status on current development efforts, sprints, sprint planning, and discuss any risks, blockers, or impediments 2. Provide status on Sprint + 1 planning and user stories 3. Administrative updates such as upcoming calendar events, etc. If requested, the Contractor shall provide presentation material in a format compatible with Microsoft Office.

The Contractor shall provide the Government notification within 14 calendar days of personnel leaving the effort and backfill their positions within 14 business days, or as agreed upon by the Contracting Officer. The Contractor shall be responsible for any subcontract management necessary to integrate work performed on this contract and shall be responsible and accountable for subcontractor performance.

2.1.1 Product Roadmap

The Contractor shall maintain a product roadmap which continuously and accurately reflects planned platform capabilities, functional changes, features, enhancements, system maintenance, and/or product upgrades planned against program milestones. The product roadmap shall, at a minimum, illustrate the current month + 11 months of deliverables, milestones, and slipped milestones. The product roadmap will be leveraged to groom and prioritize the product backlog and align with the Government’s priorities. The Contractor shall collaborate with the Government Product Owner(s) to document priorities and acceptance criteria for all platform features and product updates, and timelines. The contractor will collaborate with the Government to update the product roadmap as new features are proposed.

2.1.2 Monthly Status Report (MSR)

The contractor shall provide a Monthly Status Report (MSR). The MSR will outline the status of the task order to date; list by each active task area the accomplishments of the reporting period;

list issues, problem areas, and items that require Government action. The MSR is due to the Government no later than the 10th business day of each month. For each sprint, the Contractor shall document the sprint changes, additions, fixes, and implemented security in the MSR. The MSR format will be agreed upon by the Contracting Officer Representative (COR) and the Contractor and shall contain, but not limited to, the following information:

• Activities conducted and results

• Personnel by name and labor categories

• Identify any staffing changes

• Privilege Users DCWF information (required training completion date and DCWF expiration)

• Meetings attended IAW para 2.2.3 with a summary of relevant items discussed

• Proposed upcoming activities

• Open issues

• Actual and projected cost expenditures (Travel and ODCs)

• System availability and outages o Time to Restore Services IAW Section 3

• Deliverable Status o Sprint result summaries o Sprint burndown charts

• Summary of Incident Report(s)

• Change Failure Rate IAW Section 3

• Service Desk Tickets, Performance Metrics, and Reports (see 2.3.6.1 below)

2.1.2.1 Summary of Service Desk Activities

The Contractor shall provide a summary of the Service Desk activities in the Service Desk Report as part of the MSR that shall include support provided to end users or USTRANSCOM technical personnel, tickets received and closed, status of open tickets, and any trends identifying common user/technical problems, significant sustainment actions and recommendations for improvement and Service Desk metrics.

Deliverable:

• Product Roadmap

• Monthly Status Report (MSR)

2.1.3 System for Award Management (SAM)

The contractor shall report in the System for Award Management (SAM): 1) the total dollar amount invoiced for services performed during the previous Government fiscal year under the contract; 2) the Prime Contractor direct labor hours expended on the services performed during the previous Government fiscal year; and 3) if applicable Tier 1 subcontract number, including DUNS number/Unique Entity Identifier (UEI) and name, and the number of subcontractor direct labor hours expended under the contract. Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September 30.

2.1.4 Kick-off Meeting

The contractor shall participate in a virtual technical kickoff meeting within 10 business days after contract award. The contractor shall introduce key personnel and present proposed team composition, provide details of the intended technical approach, present task execution plan with schedules, meeting cadences, and Roadmap. A list of attendees is to be provided to the Contracting Office within sufficient time for the Government to set-up the meeting. The contractor shall take meeting minutes and provide to the Government no later than 7 business days following the meeting.

2.1.5 Contract Transition

Prior to contract expiration, at the government’s discretion, the Contractor shall provide at a minimum all materials and support necessary to accomplish a seamless and expeditious transition of the tasks identified in this PWS to the incoming Contractor. The Contractor shall include electronic copies of the following: all in-progress working files, and final phase out meeting with Government, incumbent and the new Contractor. The Contractor shall support a formal contract closeout process, including the documenting of lessons learned throughout the life of the contract. All deliverables shall be provided forty-five (45) business days before the end of the contract period of performance. If transition of system support and sustainment transitions to another company, the incumbent contractor shall:

• Cooperate with the new company in understanding the platform’s code and configuration.

• Provide all documentation generated during all phases of this contract, organized logically.

• Provide all passwords, keys, and credentials for all environments as well as any support or development tools used.

• The contents of the ITS, or the tool accounts itself, shall be accurately transitioned to the new contractor or the Government in the most complete and efficient way possible.

• Once the Government Contracting Officer has certified the transition is complete, the incumbent contractor shall retain the data and documentation for three months and then shall destroy / delete all Government owned data and documentation.

2.2 Task Area 2: Systems Engineering

2.2.1 Issue Management

The Contractor shall manage TCODE issue management processes (Epics, Features, User Stories, Spikes) for changes to the ecosystem and the processes that support the capabilities within the scope of this contract. The Contractor shall input and/or maintain all issue data in the approved ITS tool. Issues will target any data modifications, technical information queries, documentation creation or changes, configurations, software defects, incidents, problems, software feature requests, emerging system requirements, or new ecosystem capabilities. The Contractor shall create subjective estimates based upon the perceived size of effort, complexity of the envisioned capability, and doubts about implementation concepts.

The Contractor shall manage issues from creation through fulfillment. The Contractor shall ensure all technical data generated to resolve the issue is under change control and is fully linked to work items that show traceability to design changes, configurable items, test cases, and test results. The Contractor shall complete recurring backlog grooming with the PM IPT and the Technical IPT to properly prioritize resources and requirements from the program’s issue backlog.

Deliverables:

• Backlogs

2.2.2 Requirements Elaboration

The Contractor shall collaborate with the Government to derive the functional requirements of a requested change to TCODE capabilities to accomplish the following:

2.2.2.1 The Contractor shall adhere to the Government’s CCB process (e.g., platform, Government, or customer change request) and shall produce requirements specifications such as: timeline, cost impact, security impact analysis, technical approach with feasible solutions for all proposed requirements.

2.2.2.2 The Contractor shall ensure all products required under this contract are included and executed as appropriate within backlog grooming efforts.

2.2.2.3 The Contractor shall document functional requirements via Epics. Epics shall include supplementary specifications such as: expected system response, use case scenarios, decision tables, state models, data models, process models as applicable, security impact analysis, proposed architecture changes, cost impact, and test strategy.

2.2.2.4 The Contractor shall identify new and/or modified features and enhancements from use cases, supplementary specifications, feature requests, and user input. Deconstruct features into derived requirements suitable for development & implementation. Identify and document possible pain points, functionality/platform gaps, and opportunities for system enhancements into the ITS for review at the CCB.

2.2.2.5 The Contractor shall apply secure software development and secure system engineering principles IAW NIST SP 800-160 and NIST SP 800-218 (respectively) to extend requested features to meet the security functional, security strength, and security assurance requirements identified by the RMF controls documented in the applicable System Security Plan (SSP).

2.2.2.6 The Contractor shall Identify and document the potential impact of the proposed change on any applicable security controls (security impact analysis) and program cost.

2.2.2.7 The Contractor shall maintain the product backlog under the direction of the Government Product Owner. The product backlog serves as the primary source for all derived requirements.

Product Backlog Maintenance will ensure each derived requirement is well-defined, typically including the following elements:

• User story clearly identifying the capability this derived requirement will provide

• Technical requirements and considerations for the development team to implement this user story

• Projected sustainment cost of the new feature (if applicable).

• Clearly defined and testable acceptance criteria, to be approved by the Government

Product Owner

• An analysis of the security impact of the user story, including potential changes to RMF security control test results and supporting documentation. Required changes to supporting documentation will typically be included as an acceptance criterion for user stories.

2.2.2.8 The Contractor shall collaborate with the Government to prioritize the product backlog during bi-weekly backlog grooming sessions. The contractor shall align the product backlog with the product roadmap referenced in section 2.1.1 (Product Roadmap).

2.2.2.9 IAW Section 2.2.3, the Contractor shall facilitate any stakeholder briefings, meetings, and/or elicitation sessions.

2.2.2.10 The Contractor shall execute requirements review with stakeholders and record results of reviews using the TCODE ITS and update requirements data as a result of the reviews.

Obtain approval from the CCB for all proposed feature changes to the system prior to incorporating in the backlog.

Deliverables:

• Use cases & Supplementary Requirement Specifications

• Input to derived requirements / user stories.

2.2.3 Integration and Government-Partner Cooperation

TCODE provides services to tenant programs and integrates with a variety of systems and stakeholders to realize the USTRANSCOM DevSecOps Ecosystem. To that end, the Contractor shall support coordination and management for these partner engagements.

2.2.3.1 The Contractor shall coordinate integration and releasing activities to include dependencies with partners (e.g., CloudOne, PlatformOne, CSSP, Tenant Teams, USTC J6, etc.), scheduling, and milestone dates. Partners may be subject to change based on DoD or USTC requirements and direction.

2.2.3.2 The Contractor shall collaborate with partners to establish the priority, scope, bounds, and resources and manage and mitigate project risks and issues regarding milestone dates and dependencies, blockers, and proper escalation mechanisms Coordinate with partners on the development and execution of integration testing of all interfaces which shall occur in a partner integration environment that is configured by the TCODE program. As requested by the Government, conduct Technical Exchange Meetings (TEMs) to expedite this subtask. Manage and coordinate touch points with partners to ensure early communication of partner integration needs, schedule alignment, and status on partner dependent development to ensure partner alignment with all project schedules and milestones.

2.2.3.3 The Contractor shall manage partner outage awareness and communication by ensuring partners are aware of schedule alignment, milestone dates, and due dates. Communicate partner outages and the impacts to TCODE system up time and user satisfaction; perform resolution, corrective, and preventive actions as necessary; and notify stakeholders of actions completed and impact to systems.

2.2.3.4 The Contractor shall manage data across environments including staging of data and data used for both scenario testing, validation, and demonstrations.

2.2.3.5 The Contractor shall develop documentation and support processes in adherence with USTRANSCOM and stakeholder requirements to complete partner integration, including changes, service requests, and Help Desk tickets.

Deliverables:

• Interface Design Descriptions (IDD)

• Interface Control Documents (ICD)

2.3 Task Area 3: DevSecOps Ecosystem Services

PEO-T programs with software development task areas require software factory services that are effective, extensible, and secure. The needed services include team collaboration, issue tracking, project management, source control, artifact control, CI/CD orchestration, & other tools as described by the current version of the DoD DevSecOps Fundamentals Guidebook.

The Contractor shall plan for tasks identified in this task area in accordance with Task Area 2:

Systems Engineering to the extent that is practical while sustaining the ecosystem services. The Contractor shall implement services by providing a combination of functional, engineering, and technical assistance to support design, development, modification, integration, operation, and auditing, as appropriate.

2.3.1 Software Factory Services

The Contractor shall leverage resources developed for the DoD Enterprise DSOP initiative to field requested software factory services for TCODE. Initially, this includes Government resources from DoD CIO, Cloud One (C1), Platform One (P1) Big Bang, IronBank, and commercial services offerings that have received provisional authorization from the DoD Cloud Authorization Services (DCAS) team. Unless otherwise directed by the Government, the Contractor will prefer open-source resources and open-source development patterns for the implementation of these services IAW the DoD Memorandum on Software Development and Open-Source Software, January 2022.

Current services include, but not limited to:

• Discovery Services (tcode.mil DNS)

• Identity, Credential, and Access Management for Single Sign-On

• Configuration Management Tool // Source Code Repository

• Issue Tracking System // Project Management System

• Knowledge Management Tool

• Team Collaboration Tool

• Logging and Monitoring System

• Vulnerability Management Tool

• Continuous Monitoring and Threat Detection Systems

Additional services beyond the current portfolio may be requested by the Government and the TCODE tenants and implemented by the Contractor. For all services, the Contractor shall:

• Develop necessary Infrastructure as Code/Configuration as Code (IaC/CaC) to allow the automated deployment of software factory services

• Create, publish, manage, and maintain any technical documentation (including drawings, diagrams, etc.) and training materials needed for lifecycle sustainment of software factory services

• Continuously work with other DoD teams to improve DoD Enterprise DevSecOps deployments

• Include all supporting third party software into the TCODE Vulnerability Management process.

• Meet requirements for a TCODE Certificate to Field (CtF) to achieve authorization for any custom-built software components, including passing TCODE CI/CD security gates and providing required security, and component/application documentation.

2.3.2 Assessment & Authorization

As requested by the Government, the Contractor shall perform activities from Task Area 6:

Secure Development, Configuration, and Assessment Support.

2.3.3 Operations & Maintenance

The Contractor shall perform operations and maintenance tasks to sustain services that are provisioned as a part of the TCODE Software Factory. This includes performance monitoring and bug fixes and preventing system/production failure by working with hosting staff to properly engineer and deploy capabilities to support performance. In addition, O&M support activities include software improvements and correcting production software and data defects with the goal of increasing efficiency and reliability on a continuous basis by deploying patches/upgrades as needed.

To the maximum extent practical, the Contractor shall develop IaC/CaC changes to allow for the automated fulfillment of O&M responsibilities. In all cases, the O&M Contractor shall perform configuration management, leverage integrity verification tools, and create & maintain runbooks to document change processes that comply with applicable system security plans. O&M responsibilities include:

• Maintain, configure, test, and deliver maintenance releases to sustain the deployed software factory services

• Coordinate and schedule Authorized Service Interruptions (ASIs)

• Conduct patching and upgrades to ensure services are supported and free of defects

• Respond to incidents to ensure confidentiality, integrity, and availability of the TCODE software factory services

• Provide support to new tenants while transitioning software developer teams to the

TCODE ecosystem

• Performance monitoring and reporting, including systems and data analysis to determine failure rates

• Review logs for anomalous behavior

• Facilitate training for Government personnel that support lifecycle sustainment processes

2.3.4 Vulnerability Management

The Contractor shall monitor and analyze Information Assurance Vulnerability Management (IAVM) Notices, USTRANSCOM Security Notifications, United States Computer Emergency Readiness Team (US-CERT), Cyber Task Orders (CTO), Cyber Security Service Provider alerts, Cyber Operations Center alerts, vendor security advisories, and other sources of threat intel that pertain to the services sustained under this task area. The Contractor shall determine system impact, identify mitigating factors, and provide recommendations to the Government regarding potential courses of action. The Contractor’s recommendations shall align with the security objectives of the effected system(s). The Contractor shall ensure that cybersecurity remediation, patch deployments, and other significant security activities are considered in the prioritization with the Government.

2.3.5 Cutover Phase Support

The Contractor shall provide cutover support to include testing. The Contractor shall prepare tenant application for testing and validation of operational suitability. The Contractor shall perform load testing to ensure usability for applications’ maximum concurrent users. The Contractor shall provide User Acceptance Test (UAT) support for functional validation of operational suitability. The Contractor shall document the results of the UAT within the ITS (e.g., Gitlab); and shall identify, track, and remediate deficiencies from the UAT prior to Government acceptance. After Government acceptance, the Contractor shall cutover the tenant application to the Production environment. The contractor shall provide operational support alongside the tenant Sustainment Developer for a period of 30 days after the application goes live in TCODE.

2.3.6 Production Monitoring and Platform Support

2.3.6.1 Service Desk Support

The Contractor shall, upon notification from stakeholders, perform the required assessment, troubleshoot, isolate, and resolve, or refer customers to the next level of help. The issue tracking tool will be used to record, dispatch, and manage incidents IAW Task Area 2: Systems Engineering. The Contractor shall monitor incident progress and shall ensure customers receive an issue ID, status updates, and timely resolution. The Contractor shall respond immediately during duty hours (0800-1700 Central Time) and within 1 hour outside duty hours to escalated production support issues that cause adverse impact (i.e., system outage, work stoppage, degradation to the system security posture, or operational problems with the system), and ensure the Production system operates securely and without interruption to functional and end users.

The Contractor shall identify how to properly staff, assess, and remediate production support issues outside of duty hours. Defects that result in an adverse impact shall result in a solution in accordance with the program’s incident response plan. Defects identified through production support that do not result in an adverse impact shall be prioritized and assigned to current sprint or a future sprint by the Government depending on the impact to business operations.

2.3.6.2 Security Incident Escalation and Issue Documentation

The Contractor shall document resolutions or action taken on each incident. Incident information should be documented in the ITS with clear and concise detail, easily understood by other TCODE program personnel. The Contractor shall document actions taken and ongoing status in the ITS. The Contractor shall monitor task progress to ensure the timely resolution of problems and incidents. The Contractor shall collect and present incident metrics, identifying trends and problems, identifying root causes and action taken to correct/resolve. The Contractor shall be responsible for ensuring the description and resolution for incidents they resolve are documented clearly.

The contractor shall support incident response activities including planning incidence response activities and COA’s, developing and revising incident response plans, incorporating CSSP’s and other external parties into the incident response capability and process and participation as part of the incident response team in the event of a real, or exercise incident response.

In the event of exposure or intrusion, the Contractor shall escalate the incident in accordance with established incident response policies and plans. The incident report shall document and report loss/compromise, suspected compromise, suspicious contact, or activity involving systems accredited to process classified information. Cyber incidents shall be handled and reported IAW Attachment 5, regardless of the network and system (Contractor or Government) where the incident occurred.

The Contractor shall document the incident and support After Action Reporting, root cause analysis, and any technical analysis to complete and “after the fact” investigations, and lessons learned analysis. During an ongoing incident the contractor shall provide technical assistance and serve as part of the incident response team to support incident detection, The contractor shall, at the direction of the Government, participate in incident response and/or contingency planning exercises.

Deliverables:

• Source Code (including IaC, CaC, Test Automation, deployment scripts, etc.)

• System Administration Documentation

• Assessment Procedures for Tailored Security Controls

• Security Control Evidence

• System Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

• Network Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

• Cyber Incident Report

• Incident Response Plan

2.4 Task Area 4: Compute, Storage, and Connectivity Platforms

Tenants of TCODE need compute, storage, and connectivity platforms that provide for effective, extensible, and secure development and implementation of DoD software applications. The baseline for platforms, provided as a service by the TCODE program, leverage IaC and CaC, and create a reusable set of provably secure services with RMF inheritance for connected and disconnected configurations in both classified and unclassified environments.

The Contractor shall plan for all tasks identified in this task area and gather all pertinent information in accordance with Task Area 2: Systems Engineering. The Contractor shall provide a combination of functional, engineering, and technical assistance to support design, development, modification, and integration of the requested technologies onto the TCODE platform.

2.4.1 TCODE Platform Baseline

TCODE Platforms are the deployed instances of TCODE platform configuration baseline. The baseline include Kubernetes configuration, CSO configurations, VM images, database clusters, service mesh, network security tools, application monitoring tools, etc. The Contractor shall develop IaC/CaC to maximize portability among infrastructure providers, including both provisionally-authorized cloud service providers (CSP) and on-premises infrastructure. The Contractor shall leverage open technologies such as Terraform, Ansible, Helm, and Kubernetes for sustainment of the platform baseline. The Contractor shall maintain the configuration baseline, and ensure updates to TCODE Platforms from the baseline follow a timely release cadence.

The Contractor shall support the technologies that compose the TCODE platform configuration baseline, including (but not limited to):

• CI/CD Executors with Government selected orchestrator

• Big Bang Core with AWS GovCloud EKS (IL4/IL5)

• ECS Fargate with AWS GovCloud (IL4/IL5/IL6)

• MS SQL Server in Cloud One with AWS RDS (IL4/IL5/IL6)

• PostgreSQL in Cloud One with AWS RDS (IL4/IL5)

• MariaDB in Cloud One with AWS RDS (IL4/IL5)

For all source code, scripts, data files, and all other Computer Software Configuration Items (CSCIs) developed under this task area, the Contractor shall utilize TCODE change control processes to include baselines and supporting documentation. The Contractor shall employ the change control process and tools through developmental, testing, and operational environments to identify, track and release all changes. The change control processes shall leverage User Acceptance Testing / Government Witness Testing (UAT/GWT) environments for security impact analysis with analysis criteria as defined by the Government, and continuously monitor for uncontrolled changes using automated integrity verification tools.

This initiative is one of many similar efforts across the Government and the commercial sector.

The Contractor shall seek out partners for the development of hardened platform components (e.g. Big Bang Core) with in-built continuous monitoring, leverage existing work, and notify the Government when contributions should be proposed to upstream communities (e.g. IronBank).

2.4.2 Assessment & Authorization

As requested by the Government, the Contractor shall perform activities from Task Area 6:

Secure Development, Configuration, Assessment Support.

2.4.3 Platform Documentation

Documentation sufficient to operate, maintain, and authorize the platform shall be provided and updated regularly. These documents shall include updates to the product roadmap, COTS products, training manuals, user manuals, system procedures, and any supporting documents necessary for the Government to sustain the platform.

All solution changes shall be documented as Epics, features, user stories, technical specifications, and/or diagrams, interface control documents, system configuration documents, and/or SV2 architectural artifacts. Additionally, documentation and artifacts will be generated and maintained in accordance with the system security plan.

Any documentation requested by the Government shall be captured during CCB working session and prioritized into the Backlog accordingly. The Contractor shall create, publish, and maintain documentation for tenant developers that describes the use and operation of the deployed platform. The documentation shall include descriptions, procedures, drawings, diagrams, charts, tables, lists, etc. as appropriate to describe the operation of the platform within a system and on a network.

2.4.4 Platform Inheritance

To enable the inheritance of security assessments for platform instances, the Contractor shall:

• Select, tailor, and implement security controls using configuration as code, to achieve:

o Centralized ISCM, to include auditing & alert generation o Standardized maintenance & incident response processes o Parameterized contingency procedures for application data o Vulnerability detection o Anomaly detection o Automated flaw remediation

• Continuously assess and monitor security control status using compliance as code

• Publish a tenant responsibility matrix to describe the control implementation (e.g. PPSM specifications) and control inheritance associated with the platform component

• Publish assessment procedures for platform deployments in formats appropriate for ingestion into the Government’s selected information assurance tool (e.g., eMASS)

• Publish evidence of implementation for inherited controls

To this end, the Contractor shall install, maintain, and monitor any resources that are necessary to realize the vision of ISCM for the platform, the software factory, and the tenant applications.

Deliverables:

• Source Code (including Infrastructure as Code, Configuration as Code, Compliance as Code, Test Automation, deployment scripts, etc.)

• Tenant Responsibility Matrix

• Assessment Procedures/Checklists for Platform Deployments

• Security Control Evidence

• Software Design Descriptions

• Interface Design Descriptions

• System Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

• Network Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

2.5 Task Area 5: Continuous Integration, Delivery, and Deployment

Tenants may be unfamiliar with the technologies utilized in the DSOP initiative. The tenant will be expected to provide the knowledge about how to create the Computer Software Configuration Items (CSCI) required to operate their system. However, tenants require orientation from the Contractor to field CSCI on the requisite platforms and operate a continuous integration, delivery, & deployment pipeline through to Production.

The Contractor shall plan for all tasks identified in this task area and gather all pertinent information in accordance with Task Area 2: Systems Engineering. The Contractor shall provide a combination of functional, engineering, and technical assistance to support design, development, modification, and integration of the pipelines needed to produce CSCI.

2.5.1 Application Pipelines

TCODE and its tenants will need pipelined processes to build, test, release, and deploy applications onto the platforms that are developed in accordance with Task Area 4: Compute, Storage, and Connectivity Platforms. Application deployments will aggregate numerous types of CSCIs, to include source code files, machine code files, configuration files, data files, and application secrets. To accommodate the various types of software products that must be supported, the Contractor shall reuse, extend, and create CI/CD pipelines to meet the needs of each program’s deployment process to compile and package CSCIs.

For all source code, scripts, data files, and all other pipeline processes developed under this task area, the Contractor shall utilize TCODE change control processes to include application pipelines and supporting documentation. The Contractor shall adhere to and support the Government’s change control process and tools to identify, track and release all changes using TCODE’s platform environments.

2.5.2 Assessment & Authorization

The Contractor shall implement application pipelines that conform to policies defined by the Government for configuration management and related security controls. The pipelines shall implement GitOps processes to create, publish, maintain, and manage changes to application pipelines. The Contractor shall produce supporting documentation to realize the standards, processes, tool options, and tool configurations supported by the TCODE SDLC. The Contractor shall validate these products align with the objectives of applicable system security plans.

As requested by the Government, the Contractor shall perform activities from Task Area 6:

Secure Development, Configuration, Assessment Support.

2.5.3 Infrastructure Support

As required by the Government, the Contractor shall provide the expertise required to establish, operate, and maintain all required environments to execute all functions supported by TCODE.

This shall include maintaining virtual machines and components, load balancers, firewalls, etc.

Additionally, the Contractor shall declare, maintain, and update the Ports, Protocols and Services (PPS) information in accordance with DoD Instruction 8551.01 and any applicable DoD, DISA, or USTRANSCOM policies and regulations.

2.5.4 Pipeline Documentation

The Contractor shall create documentation for tenant developers that describes the functions performed by the CI/CD pipelines and the prerequisites for its operation. The documentation shall include descriptions, procedures, drawings, diagrams, charts, tables, lists, etc. as appropriate to describe the operation of the pipeline within the CI/CD agent and the network communication requirements for correct operation. The documentation should take the form as a walkthrough or tutorial that (1) guides a tenant developer through the processes needed to leverage the pipeline, (2) describes all steps needed to configure the pipeline for security control inheritance, and (3) identifies specific RMF controls assessed during execution of the pipeline.

The documentation shall describe the technical details tenants need to implement to take full advantage of pipeline features and control gates, with samples of correct operation.

2.5.4.1 Pipeline Inheritance

To enable security control inheritance for software development activities, the Contractor shall integrate functional and security testing into application pipelines. Testing may include:

• Code compilation integration for multiple languages

• Unit Testing

• Behavioral Testing

• Static Code Analysis

• Software Composition Analysis / Software Bill of Materials (SBOM)

• Container Scanning

• Dynamic Code Analysis

• Automated Fuzz/Penetration Testing

• Licensing Compliance

• Secret Detection

• User Acceptance Testing

Through development of application pipelines, the Contractor shall provide checks on all rules defined in the DISA Application Security and Development (ASD), Security Technical Implementation Guide (STIG), Cloud Computing Security Requirements Guide (SRG) and any other controls from applicable system security plans. To facilitate assessment, the Contractor shall:

• Integrate configuration as code and compliance as code into application pipeline

• Document tenant responsibilities for satisfying continuous monitoring requirements

• Document tenant responsibilities for application security and compliance with the ASD

STIG

• Publish assessment procedures for application pipelines in formats appropriate for ingestion into the Government’s selected information assurance tool

• Publish evidence of implementation for inherited controls to system-level dashboards

2.5.5 Training, Orientation, & Collaboration

The Contractor shall onboard and support tenants using a repeatable process for ensuring new tenants and their applications are efficiently supported by the TCODE software factory. Tasks include:

• Produce & publish documentation and training material for tenant onboarding, with topics including:

o Account Management o Configuration Management o Incident Response o Contingency Planning

• Schedule and lead technical exchange meetings with tenants

• Demonstrate the deployment of software products into tenant environments with application pipelines

• Work with tenants to troubleshoot different aspects of application pipelines or other developer issues.

Deliverables:

• Source Code (including Infrastructure as Code, Configuration as Code, Compliance as Code, Test Automation, deployment scripts, etc.)

• Assessment Procedures/Checklists for Application Pipelines

• Security Control Evidence

• Software Design Descriptions

• Interface Design Descriptions

• System Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

• Network Information (Drawings, Diagrams, Charts, Tables, Lists, etc.)

2.6 Task Area 6: Secure Development, Configuration, and Assessment Support

The contractor shall develop, configure, and/or operate information system components and/or information systems securely, and in accordance with the current versions of DOD policy, National Institute of Standards and Technology (NIST) Special Publications (SPs), National Security Agency (NSA) publications, Committee on National Security Systems (CNSS) issuances, and United States Cyber Command (USCYBERCOM) tasking orders, and requirements; support improving cyber resiliency for the information system and reducing vulnerability to the information system and the DODIN. The contractor shall support continuous monitoring and the integration of security and Risk Management Framework (RMF) activities into the Systems Development Lifecycle (SDLC) for the specific purposes of attaining and maintaining Authorization to Operate/Connect (ATO/ATC).The Contractor shall support efforts to develop, research, and implement tools, processes, and techniques needed to automate and mature continuous monitoring capabilities in support of ongoing improvements to the system security posture.

The Contractor shall have the capacity to adjust and shift requirements to remain in compliance with new or changing DoD mandates and guidance (e.g., ZeroTrust Strategy, Continuous Monitoring, ATO). The Contractor shall generate, refine, and prioritize the requirements as applicable to the DoD guidance. Specific contractual requirements are set forth below.

2.6.1 Assessment & Authorization Support

The Contractor shall create, edit, update, and maintain information system security assessment and authorization (A&A) documentation/evidence of control compliance for all applicable security control families necessary to achieve an authorization decision (ATO/ATC) or Interim Authorization to Test (IATT) and/or support continued authorization in accordance with the current version of DOD Instruction (DODI) 8500.01, Cybersecurity, DODI 8510.01, NIST Special Publication 800-37, Risk Management Framework (RMF) for DoD Information Technology (IT), Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 6510.01F, Information Assurance (IA) and Support to Computer Network Defense (CND), Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01B, Cyber Incident Handling Program, Committee on National Security Systems Instruction (CNSSI) 1253, Security Categorization and Control Selection for National Security Systems, NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, and NIST SP 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans.

The government will be responsible for providing USTRANSCOM-specific policy requirements associated with the program, while the developer will be responsible for building and maintaining information system security…