Under active development Content is continuously updated and improved

KSI-CED-DETReviewing Development and Engineering Training

LOW
MODERATE

Formerly KSI-CED-03

>Control Description

Persistently review the effectiveness of role-specific training given to development and engineering staff that covers best practices for delivering secure software.
Defined terms:
Persistently

>NIST 800-53 Controls

>Trust Center Components
4

Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.

From the field: Mature implementations express encryption-at-rest as an automatically enforced property — policy engines preventing unencrypted storage from deploying, configuration scanning verifying encryption across all storage tiers, and key rotation tracked as a dashboard metric. Encryption status is verified continuously through AWS Config rules, Azure Policy, or equivalent, making it a runtime-verified property rather than a documented claim.

Encryption at Rest Documentation

Product Security Features

How encryption-at-rest is implemented and enforced — algorithms, key lengths, FIPS validation, and automated enforcement mechanisms

Automated: AWS Config rules verify encryption at rest across all storage services

Data Encryption Architecture

Architecture & Diagrams

Architecture expressing where data is encrypted at rest — storage tiers, databases, and which FIPS-validated modules serve each encryption point

Encryption Policy Enforcement

Product Security Features

Automated enforcement preventing unencrypted storage — policy engines validate encryption requirements before resource provisioning

Automated: Policy engine logs show blocked unencrypted resource creation attempts

Key Management Practices

Processes & Procedures

Key management including rotation schedules, access controls, and HSM usage

>Programmatic Queries

Beta
CI/CD

CLI Commands

Check developer commit activity
gh api repos/{owner}/{repo}/stats/contributors --jq '.[].{author: .author.login, total_commits: .total, recent_weeks: [.weeks[-4:][] | .c] | add}'
List contributors
gh api repos/{owner}/{repo}/contributors --jq '.[].{login,contributions}' | head -20

>20x Assessment Focus Areas

Aligned with FedRAMP 20x Phase Two assessment methodology

Completeness & Coverage:

  • Does secure development training cover all relevant topics — OWASP Top 10, secure API design, secrets management, dependency security, and cloud-native security patterns?
  • Are all development and engineering staff included — full-time employees, contractors, and third-party developers with commit access?
  • How do you ensure training addresses the specific languages, frameworks, and platforms your developers use, rather than only generic secure coding principles?
  • When new developers join or new technologies are adopted, what process ensures training is completed before they contribute code to the CSO?

Automation & Validation:

  • What automated gates in the development pipeline enforce that developers have completed required security training before they can merge code?
  • How do you measure whether training actually improves code security — for example, do you track SAST/DAST finding rates before and after training?
  • What happens if a developer fails a practical secure coding assessment — are they blocked from production code contributions until they pass?
  • How do you detect if training content becomes outdated — do you track whether training modules address recently disclosed vulnerability classes?

Inventory & Integration:

  • How does your LMS or training platform integrate with your identity provider and HR system to ensure the developer roster is always current?
  • What tools correlate developer training completion with code authorship to identify untrained contributors?
  • How does training completion data integrate with your CI/CD pipeline to enforce contribution gates?
  • Are training requirements tracked per role (frontend, backend, infrastructure, SRE), or is there only a single training requirement for all developers?

Continuous Evidence & Schedules:

  • How frequently is secure development training required (annual, semi-annual), and what evidence proves every developer is current?
  • Is training completion and effectiveness data available via API or dashboard, or only as manual LMS reports?
  • How do you demonstrate that training effectiveness is persistently reviewed — what metrics trend over time?
  • What evidence shows training content has been updated in response to new vulnerability trends or past security findings in your codebase?

Update History

2026-02-04Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

Ask AI

Configure your API key to use AI features.