| BR-ADM-1
|
Use of the CMS Life Cycle Is Mandatory |
| BR-ADM-2
|
The Development Methodology and Artifacts Must Be Documented |
| BR-SA-1
|
Use CMS Shared Services |
| BR-SA-2
|
Integrate with the CMS Identity Management Services |
| BR-SA-3
|
No Custom Application Code Is Permitted in the Presentation Zone |
| BR-SA-4
|
Use CMS-Validated Mediation and Data Access Services to Access Data in the Data Zone |
| BR-SA-5
|
No Long-Term, Persistent Sensitive Application Data Storage in the Presentation or Application Zones |
| BR-SA-6
|
Network Communications Must Meet the TRA Rules for Encryption |
| BR-SA-7
|
Substantive Changes to the Architecture, Products, or Technology of an Existing Application Must Be Documented and Reviewed by the CMS TRB |
| BR-SA-8
|
Logging Must Be Configurable and Use Common Platform Standards |
| BR-SA-9
|
Systems Must Define Metrics for IT Health Monitoring |
| BR-SA-10
|
Applications in CMS Data Centers May Not Use Some Native Email Protocols |
| RP-SA-11
|
Servers Should Include Instrumentation for Application Performance Monitoring |
| RP-SA-12
|
Minimize Manual File Copying by Using Integrating File Transfer Automation |
| RP-SA-13
|
Consider Data Services in the Data Zone to Improve Performance of Database-Intensive Services |
| BR-SA-14
|
Use of Short Message Service / Multimedia Message Service by CMS Applications |
| BR-SA-15
|
Protect Sensitive Information in Transit |
| BR-SA-16
|
Protect Sensitive Information at Rest |
| BR-SD-1
|
External Configuration Is Mandatory |
| BR-SD-2
|
Web-Based User Interfaces Must Comply with TRA Guidance |
| RP-SD-3
|
Configurations Should Be Validated and Checked on Each System Startup |
| RP-SD-4
|
Consider Dependency Injection to Achieve External Configuration |
| RP-SD-5
|
External System Dependencies Should Be Stubbed Out for Development and Testing |
| RP-SD-6
|
Timestamps Logged by the System Must Be in UTC or GMT and Should Be Expressed in ISO-8601 Format |
| RP-SD-7
|
Software Should Be Designed Based on SOA Principles |
| RP-SD-8
|
Consider Non-Blocking Service Implementations to Improve Performance and Scalability |
| BR-SC-1
|
Inventory all Open Source Software Licenses |
| BR-SC-2
|
All Custom-Written Source Code for a Project Must Conform to an Identified Coding Standard |
| RP-SC-3
|
Do Not Intermingle Code in Different Programming Languages in the Same File |
| RP-SC-2
|
Capture Code Metrics and Defect Tracking Metrics for Quality Improvement Purposes |
| RP-SC-5
|
When Using Flat Files for Data Transfer, Include Helpful Metadata in the File |
| RP-SC-6
|
When Using Flat Files for Data Transfer, Consider Including a Machine-Readable Schema |
| RP-SC-7
|
Use Decimal Math Types for Financial Calculations |
| RP-SC-8
|
Consider Synthetic Transactions |
| BR-SQ-1
|
All Custom-Written Software Must Have Associated Automated Unit Tests |
| BR-SQ-2
|
Run Automated Unit Tests during Full Builds |
| BR-SQ-3
|
Automated Unit Tests Must Use a Commercially Available Unit Testing Framework or Test Runner |
| BR-SQ-4
|
All CMS User Interfaces Must Meet Section 508 Accessibility Requirements |
| BR-SQ-5
|
Manual Code and Design Reviews Are Mandatory |
| BR-SQ-6
|
De-Identification of Production Data Is Required in Non-Production Environments |
| RP-SQ-7
|
Code Coverage Analysis Is Highly Encouraged During Unit Testing |
| RP-SQ-8
|
Use Static Analysis Tools During Build to Catch Common Coding Errors |
| RP-SQ-9
|
Developers Assist Testers in Generating Test Data |
| BR-SS-1
|
All Software on CMS Production Servers Must Have Recorded Provenance |
| BR-SS-2
|
Use NIST SP 800-132-Specified Salted Hashes to Store Passwords |
| BR-SS-3
|
SQL Code Must Use Binding Variables |
| BR-SS-4
|
Check for Common Security Vulnerabilities |
| BR-SS-5
|
Use Static Analysis Tools to Catch Common Security Weaknesses |
| RP-SS-6
|
Use Profiling to Perform Dynamic Code Analysis |
| BR-SS-7
|
Error Handling Must Not Reveal Information That Could Lead to an Exploit |
| RP-SS-8
|
Perform Threat Modeling During the Design Phase to Identify Potential System Threats |
| BR-ED-1
|
Custom-Written Software Must Include Inline Documentation for Public APIs |
| BR-ED-2
|
The CMS TLC Phase Review Artifacts Must Be Produced |
| RP-ED-3
|
Engineering Documentation Should Be Versioned Along with Source Code in the Same Repository |
| RP-SM-1
|
Consider Building Self-Diagnosis Capability into Systems |
| RP-SM-2
|
Consider Designing Maintenance Capability into Systems |
| BR-DBM-1
|
Systems Must Meet Federal Record Management Requirements |
| BR-DBM-2
|
Systems Must Meet Federal Government FOIA Requirements |
| BR-DBM-3
|
Systems Must Meet CMS Data and Database Management Standards |
| BR-SCM-1
|
All Source Code Must Be Checked in to Version Control |
| BR-SCM-2
|
All Code Must Be Baselined Prior to Release into Implementation, Validation, and ATO(ed) Production Environments |
| RP-SCM-3
|
Apply Database-Oriented Configuration Management Practices |
| BR-SCM-4
|
Configurations Must Be Checked in to Version Control |
| BR-DIT-1
|
All CMS Software Development Projects Must Use a Defect Tracking System |
| BR-DIT-2
|
A Defined Defect Classification Standard Is Mandatory |
| RP-DIT-3
|
Defects Should Be Correlated to Baselines |
| BR-SBI-1
|
All Builds Must Occur in Controlled Environments |
| BR-SBI-2
|
All Production-Deployed Custom Code Must Be Built and Installed from Version-Controlled Source Code |
| BR-SBI-3
|
Production Builds Must Have Zero Compile Errors |
| RP-SBI-4
|
Use Explicit Library and Build Dependency Management |
| RP-SBI-5
|
Consider Instituting Continuous Integration |
| BR-PD-1
|
Software Must Be Packaged for Deployment |
| BR-PD-2
|
Software Target Packaging Must Be in Either the Operating System or Language Platform Native Form |
| BR-PD-3
|
Database Changes Must Include Back-Out Scripts |
| RP-PD-4
|
The Package Manifest Should Include a List of All Defects Corrected in the Release |
| RP-PD-5
|
Changes Applied to Databases Should Be Recorded in the Database Itself |
| RP-PD-6
|
Support A/B Testing of User Interfaces |
| BR-D-1
|
Developers Do Not Have Unsupervised Administrative Access to Production Servers |
| BR-D-2
|
All Installation and Back-Out Scripts Must Have Been Tested in Lower Environments Prior to Use in Production |
| RP-D-3
|
Support Rolling Deployment |
| RP-D-4
|
Use Feature Flags to Gradually Introduce New Features to Users |
| RP-D-5
|
Deployment Should Integrate with Monitoring to Coordinate Outages |
| RP-D-6
|
Support Rollback of Package Installation |
| RP-D-7
|
Support Automated Startup, Shutdown, and Maintenance Mode Entry / Exit |
| RP-RM-1
|
Establish and Follow Organizational Standards for Deployment of Custom Software |
| RP-RM-2
|
(Retired after TRA 2018R1): Contractors Must Deliver Certain Configuration Items |
| RP-RM-3
|
(Retired after TRA 2018R1): Minimum Acceptance Test Criteria |
| BR-WS-1
|
Describe All Services |
| BR-WS-2
|
Services Must Use Standard Invocations |
| BR-WS-3
|
Services Must Validate Input and Outputs |
| BR-WS-4
|
Use TRB-Approved Data Zone Mediation and Data Access Services to Access Data in the Data Zone |
| BR-WS-5
|
Messages Must Include Timestamp and Originator |
| BR-WS-6
|
Services Must Use Open Data Formats |
| BR-WS-7
|
Web Services Must Follow CMS Encryption Policy |
| BR-WS-8
|
SOAP-Based Services Must Comply with WS-* Standards |
| BR-WS-9
|
Inter-Zone Web Services Must Transverse a Mediated Service |
| BR-WS-10
|
Web Services Must Be Version Numbered |
| BR-WS-11
|
Use Certificate-Based Mutual Authentication for Machine-to-Machine Web Services |
| BR-WS-12
|
Messages Must Pass through All Intermediate Zones |
| BR-WS-13
|
CMS Public APIs Must Be Published |
| BR-UX-1
|
Ensure Usability and Accessibility |
| BR-UX-2
|
Collect Feedback |
| BR-UX-3
|
Provide Multilingual Capability |
| BR-UX-4
|
Ensure Privacy and Security |
| BR-UI-5
|
Skip Navigation |
| BR-UI-6
|
Provide a Home Page Link |
| BR-UI-7
|
No Frames |
| BR-UI-8
|
Keyboard and Mouse |
| BR-UI-9
|
Phishing and Redirection Prevention |
| BR-UI-10
|
Cross-Site Request Forgery Prevention |
| BR-UI-12
|
Authentication |
| BR-UI-13
|
Session Management |
| BR-UI-14
|
Protecting PHI |
| BR-UI-15
|
User Identifiers |
| BR-UI-16
|
Input Validation |
| BR-UI-17
|
(Deprecated after TRA 2017R1): Information Security |
| BR-UI-18
|
Need to Disclose |
| BR-UI-19
|
Color Contrast Ratio |
| BR-UI-20
|
(Deprecated after TRA 2017R1): Standard Colors |
| BR-UI-21
|
(Deprecated after TRA 2017R1): Deprecated Elements |
| BR-UI-22
|
(Deprecated after TRA 2017R1): CSS Version |
| BR-UI-23
|
(Deprecated after TRA 2017R1): HTML Version |
| BR-UI-24
|
(Deprecated after TRA 2017R1): JavaScript |
| BR-UI-25
|
Scripts Compatibility |
| BR-UI-26
|
(Deprecated after TRA 2017R1): Logo |
| BR-OSS-1
|
Products in Use at CMS that Provide the Required Functionality Are Preferred |
| BR-OSS-2
|
Criteria for Evaluation |
| BR-OSS-3
|
Total Cost of Ownership |
| BR-OSS-4
|
License Compatibility for Using OSS |
| BR-OSS-5
|
Use OSS Built from a Controlled Source |
| BR-OSS-6
|
Binary Package Management Is Mandatory |
| BR-OSS-7
|
(Deprecated after TRA 2017R1): Modification of Open Source Is Prohibited |
| BR-OSS-8
|
(Deprecated after TRA 2017R1): Use Only Published Final Releases of Project Packages in Testing Validation and Production Deployment Systems |
| BR-OSS-10
|
CMS OSS Code Released as CMS-Managed Code Requires a Governance and Support Model |
| BR-OSS-11
|
CMS OSS Code Released as Unmanaged Code Must Be Identified as Such |
| BR-OSS-12
|
CMS-Released OSS Code Must Include Automated Unit Tests, Build Scripts and Be Checked for Software Vulnerabilities |
| BR-OSS-13
|
CMS-Released OSS Code Must Include Documentation Accessible to the Open Source Community |
| BR-OSS-14
|
Use the CMS’s External GitHub Repository and Code.gov for CMS-Released OSS Code |
| RP-OSS-1
|
Provide Ample Documentation with CMS-Released OSS Code |
| RP-OSS-2
|
Implement the Tools to Support the Community Around a CMS-Released OSS Project |
| BR-P-1
|
Each Portlet Must Include a Deployment Descriptor as Specified in JSR 286 |
| BR-P-2
|
Each Portlet Must Implement Specific Portlet Life-Cycle Management Functions as Specified in JSR 286 |
| BR-P-3
|
Each Portlet Must Log Events via Portlet Container Logging Functions |
| BR-P-4
|
If Functionality to Customize / Personalize the Portlet User Interface Is Provided, It Must Be Consistent with JSR 286 |
| BR-P-5
|
Each Portlet Must Control Access to Content / Functionality Based on User and Role Information via the Portal |
| BR-P-6
|
Each Portlet Must Use Portal Services to Authenticate Users |
| BR-P-7
|
Each Portlet Must Securely Transport Sensitive Content |
| BR-P-8
|
Inter-Portlet Communication Must Be Performed Only by Either Public Render Parameters or Events as Specified in JSR 286 |
| BR-P-9
|
Remote Portlets Must Follow Web Service Standards |
| BR-CA-1
|
The CMS Zonal Architecture Must Be Preserved
|
| BR-CA-2
|
Lower Environments Must Be Separated from Production |
| BR-CA-3
|
The CMS TRA Zonal Hierarchy Will Be Enforced |
| BR-CA-4
|
Interfaces between the Containers Implemented in Each Zone Must Be Locked Down (Source / Destination) |
| BR-CA-5
|
Container Traffic to Non-Container or External Destinations Must Follow Existing TRA Rules |
| RP-CA-1
|
Force Containers to Write to Container-Specific File Systems |
| RP-CA-2
|
Implement Read-Only File Systems Whenever Possible |
| RP-CA-3
|
Run Your Containers as Non-Root Whenever Possible |
| RP-CA-4
|
Create Containers with the Least Privilege Possible |
| RP-CA-6
|
Use a Security Mechanism for Mandatory Access Controls |
| RP-CA-7
|
Use Cgroups |
| RP-CA-8
|
Use a Secure Computing Mode Profile |
| RP-CA-9
|
Harden All Containers / Components |
| RP-CA-10
|
Validate All Third-Party Containerized Applications before Implementation |
| RP-CA-11
|
Maintain the Immutability of Your Containers |
| BR-OR-1
|
Container Images Must Be Hardened |
| BR-OR-2
|
Use Security Monitoring on Containers |
| BR-OR-3
|
The Deployment Infrastructure for Containers Must Be Hardened and Monitored |
| BR-OR-4
|
Containers Use Must Respect the Multi-Zone Architecture |
| BR-OR-5
|
Libraries of Containers Must Be Maintained in CMS-Only Stores |
| BR-OR-6
|
Required Orchestration Capabilities |
| RP-OR-7
|
Prefer Container Orchestration Tools That Allow for Container Motion |
| RP-OR-8
|
Rolling Upgrades |
| BR-LD-1
|
Avoid Using Lambda for CMS Sensitive Data |
| BR-LD-2
|
Integrate with CMS Enterprise Security |
| BR-LD-3
|
Configure Lambda to Control the Cost / Budget |
| BR-LD-4
|
Do Not Use the Local Volatile Storage of Lambda Containers for Persistent Data |
| BR-LD-5
|
Use Lambda Only for Stateless Transactions |
| RP-LD-1
|
Avoid Complex Application Programming or Workflows in Lambda |
| BR-CM-1
|
Projects Must Produce a Configuration Management Plan |
| BR-CM-2
|
Projects Must Identify Items to Be Placed under Configuration Control |
| BR-CM-3
|
Significant Changes to Configuration Items of a System or Component Managed by a CCB Requires the Approval of That CCB |
| BR-CM-4
|
Projects Must Maintain Accurate and Reliable CI Information |
| BR-CM-5
|
Projects Must Conduct Periodic Audits of CM Activities and Products |
| BR-CM-6
|
Projects Must Maintain Configuration Baselines |
| BR-CM-7
|
Follow the CMS ARS Hierarchy for Security Configuration |