{"data":{"id":"SP-041","slug":"secure-application-baseline","title":"Secure Application Baseline for Developers","description":"Architecture pattern bridging the gap between security control frameworks and practical software implementation. Provides developer-centric guidance for each control area: how to detect what is already implemented, how to identify gaps against control requirements, and how to implement what is missing in a modern application stack. Covers infrastructure as code baselines, secrets management, dependency security (SBOM/SLSA), authentication and authorisation patterns, structured logging, input validation, container security, CI/CD pipeline hardening, and API security. Designed for engineering teams building cloud-native applications who need to satisfy NIST 800-53 controls without translating from compliance language.","url":"https://www.opensecurityarchitecture.org/patterns/sp-041","metadata":{"release":"26.02","classification":"Application Security","status":"deprecated","type":"pattern","datePublished":"2026-02-09","dateModified":"2026-03-14","deprecatedDate":"2026-03-14","deprecatedReason":"Merged into SP-028 (Secure DevOps Pipeline). The unique developer-facing content (authentication patterns, input validation, structured logging, API security hardening, and the Detect/Gap/Implement methodology) has been incorporated into SP-028. See SP-028 for the combined pattern.","supersededBy":"SP-028","authors":["Samplawski","Vitruvius"],"reviewers":[],"provenance":"Krzysztof Samplawski identified the core problem from his experience as a developer and entrepreneur building CharacterSphere.ai: security controls are written for GRC professionals, not the engineers who implement them. The gap between a control statement and a working implementation is where most security programmes fail. This pattern exists to close that gap."},"diagram":{"svg":"/images/sp-041-secure-application-baseline.svg","png":""},"content":{"description":"Security control frameworks like NIST 800-53 define what an organisation should do, not how a developer should build it. A control statement such as 'the organisation develops, documents, and maintains a current baseline configuration of the information system' (CM-02) tells a compliance officer what to audit but tells an engineer nothing about Terraform state files, Kubernetes admission controllers, or CIS benchmark automation.\n\nThis gap is structural. Control frameworks are deliberately technology-agnostic and written at an organisational level. The translation from control requirement to code implementation happens informally — in the heads of senior engineers, in tribal knowledge, in ad-hoc wiki pages that rot within months. The result: security teams write policies that developers cannot action, developers build systems that auditors cannot map to controls, and the organisation passes its audit through manual evidence collection rather than engineering discipline.\n\nThis pattern provides the missing translation layer. For each control area relevant to application development, it defines three operations that a developer can execute against their own codebase and infrastructure:\n\n1. DETECT — Automated or semi-automated checks to determine what is already implemented. These map to specific tools, commands, and configuration inspections that a developer can run today.\n\n2. GAP — How to compare the current state against the control requirement and identify what is missing. This produces a concrete list of items to implement, not an abstract risk statement.\n\n3. IMPLEMENT — Practical guidance for closing each gap using modern tools and patterns. Framework-agnostic where possible, with specific examples for common stacks (AWS/GCP/Azure, Kubernetes, Terraform, GitHub Actions/GitLab CI).\n\nThe pattern is organised around developer concerns rather than control families. A developer thinks about 'how do I manage secrets' not 'how do I satisfy SC-12, SC-28, and IA-05'. The NIST mapping is provided for each area so that compliance teams can trace implementations back to controls.\n\nThis is the pattern that makes other patterns actionable. SP-027 (Secure AI Integration) tells you what controls an AI system needs. SP-041 tells you how to implement them.\n\nAssessment scoring for this pattern uses a developer-centric maturity scale rather than the traditional CMMI model:\n\n1. Not implemented, not planned\n2. Planned, not yet implemented\n3. Implemented in dev/test/QA, not live in production\n4. Live in production, not monitored\n5. Live in production, measured and monitored\n\nThis maps to the actual deployment lifecycle that engineering teams experience. A control at level 3 has working code in a staging environment but has not yet been promoted to production. A control at level 4 is running in production but lacks observability — it works until it doesn't, and you won't know when it stops. Level 5 means the control is deployed, measured, and has alerting that detects degradation or bypass.","keyControlAreas":["Infrastructure Baseline as Code (CM-02, CM-06, CM-07): DETECT — Scan for infrastructure drift between declared state (Terraform/CloudFormation/Pulumi) and actual cloud resources using tools like terraform plan, driftctl, or AWS Config rules. Check for undocumented manual changes via cloud provider audit trails. GAP — Compare deployed configuration against CIS Benchmarks for your platform (AWS CIS, Kubernetes CIS, Docker CIS) using automated scanners (Prowler, kube-bench, Docker Bench). Any resource not in IaC or any configuration diverging from benchmark is a gap. IMPLEMENT — Declare all infrastructure in version-controlled IaC with no manual console changes permitted. Enforce via Service Control Policies (AWS) or Organisation Policies (GCP). Run CIS benchmark checks in CI/CD pipeline as a gate. Tag all resources with owning team and IaC source reference. Drift detection on a scheduled basis with alerts on divergence.","Secrets and Key Management (SC-12, SC-28, IA-05): DETECT — Scan repositories for committed secrets using gitleaks, truffleHog, or GitHub secret scanning. Check environment variables and config files for plaintext credentials. Audit key rotation dates in your secrets manager. GAP — Any secret in source code, any credential older than rotation policy, any service using long-lived API keys instead of short-lived tokens, any secret not in a dedicated secrets manager. IMPLEMENT — Centralise all secrets in HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault. Application code reads secrets from the manager at runtime, never from environment variables baked into images. Automate rotation with maximum 90-day lifecycle. Use workload identity (IRSA, Workload Identity Federation) instead of static credentials. Pre-commit hooks block secret commits.","Dependency and Supply Chain Security (SR-03, SR-04, SA-04, SA-11): DETECT — Generate SBOM (CycloneDX or SPDX format) from your package manager (npm, pip, Maven, Go modules). Run vulnerability scans (Snyk, Trivy, Grype, npm audit). Check for SLSA provenance attestations on critical dependencies. GAP — Any dependency without a known provenance, any vulnerability above your severity threshold unfixed beyond SLA, any missing lock file, any dependency pulling from unofficial registries. IMPLEMENT — Pin all dependency versions via lock files. Enable automated vulnerability scanning in CI with severity-gated blocking (critical/high block merge). Generate and publish SBOM with each release. Verify SLSA provenance for critical dependencies. Use private registry mirrors for supply chain isolation. Dependabot or Renovate for automated update PRs with test validation.","Authentication and Authorisation (AC-03, AC-06, IA-02, IA-08): DETECT — Map all authentication paths in your application (login, API keys, service-to-service, OAuth flows). Check session configuration (timeout, rotation, secure flags). Audit authorisation checks on every endpoint. GAP — Any endpoint without authentication, any authorisation check done client-side only, any use of custom auth instead of standard protocols (OIDC/OAuth 2.0), any service-to-service communication without mutual authentication, any hardcoded roles or permissions. IMPLEMENT — Use OIDC for user authentication via an established IdP (Auth0, Okta, Keycloak, cloud-native). Implement RBAC or ABAC at the API gateway or middleware layer. Every API endpoint must declare its required permissions. Service-to-service uses mTLS or signed JWTs with short expiry. Session tokens: HttpOnly, Secure, SameSite=Strict, rotated on privilege change. MFA for all privileged operations.","Structured Logging and Audit Trail (AU-02, AU-03, AU-06, AU-12): DETECT — Check log output format (structured JSON vs unstructured text). Verify what events are logged: authentication success/failure, authorisation decisions, data access, configuration changes, errors. Check for PII in logs. GAP — Any security-relevant event not logged, any log in unstructured format, any PII or secrets appearing in logs, any log not forwarded to centralised collection, any gap in log retention below regulatory requirement. IMPLEMENT — Structured JSON logging with consistent schema: timestamp, correlation ID, user ID, action, resource, outcome, source IP. Log all authentication events, authorisation failures, data access to sensitive resources, configuration changes, and error conditions. Never log passwords, tokens, PII, or request/response bodies containing sensitive data. Forward to centralised logging (ELK, Datadog, CloudWatch Logs) with retention meeting regulatory requirements. Alert on anomalous patterns.","Input Validation and Output Encoding (SI-10, SI-15, SC-08): DETECT — Audit all user input entry points: API request bodies, query parameters, headers, file uploads, WebSocket messages. Check for parameterised queries vs string concatenation in database access. Check output encoding in HTML rendering. GAP — Any user input used without validation, any SQL/NoSQL query built with string concatenation, any HTML output without encoding, any file upload without type/size validation, any API accepting unbounded input. IMPLEMENT — Validate all input at the API boundary using schema validation (JSON Schema, Zod, Joi, Pydantic). Reject by default, allowlist by exception. Use parameterised queries exclusively for all database operations. Apply context-appropriate output encoding (HTML entity encoding, URL encoding, JavaScript escaping). Limit file upload types, sizes, and scan for malware. Set Content-Security-Policy headers. Rate limit all endpoints.","Container and Runtime Security (CM-07, SC-07, SI-07, SC-28): DETECT — Scan container images for vulnerabilities (Trivy, Grype). Check Dockerfile for anti-patterns: running as root, large base images, secrets in build layers. Audit Kubernetes pod security: privileged containers, host network, writable root filesystem. GAP — Any container running as root, any image from untrusted registry, any container with writable root filesystem, any pod with excessive Linux capabilities, any missing network policy allowing unrestricted pod-to-pod communication. IMPLEMENT — Minimal base images (distroless, Alpine). Run as non-root user (USER directive in Dockerfile). Read-only root filesystem with tmpfs for write paths. Drop all Linux capabilities except required. Kubernetes Pod Security Standards (restricted profile). Network policies enforcing least-privilege pod communication. Image signing with Cosign/Notation and admission controller verification (Kyverno, OPA Gatekeeper). No latest tag — pin image digests in production.","CI/CD Pipeline Security (SA-11, CM-14, SI-07, SA-15): DETECT — Audit pipeline configuration: who can modify pipeline definitions, what secrets are available to builds, whether artifacts are signed, what quality gates exist. Check for direct pushes bypassing pipeline. GAP — Any pipeline without SAST/DAST scanning, any artifact deployed without signing, any pipeline secret accessible to arbitrary branches, any production deployment without approval gate, any ability to push directly to main branch. IMPLEMENT — Branch protection: require PR review and passing CI before merge. SAST scanning (Semgrep, CodeQL, SonarQube) as merge gate. DAST scanning against staging environments. Sign all build artifacts (Cosign for containers, GPG for packages). Separate build and deploy credentials with least privilege. Pipeline-as-code in version control (no UI-only configuration). Deployment approvals for production. Audit trail of all deployments with rollback capability.","API Security Hardening (SC-08, AC-04, SC-13, SI-10): DETECT — Inventory all API endpoints (OpenAPI spec, route listing). Check TLS configuration (SSL Labs scan). Verify rate limiting, authentication, and input validation on each endpoint. Check for information disclosure in error responses. GAP — Any API endpoint without TLS, any endpoint without rate limiting, any endpoint returning stack traces or internal details in errors, any endpoint without authentication (that should have it), any missing CORS configuration. IMPLEMENT — TLS 1.2+ on all endpoints with strong cipher suites. Rate limiting per client and per endpoint (token bucket or sliding window). Schema validation on all request bodies (reject malformed early). Generic error responses in production (no stack traces, no internal paths). CORS allowlist (never wildcard in production). API versioning strategy. Request size limits. Timeout configuration to prevent slow-loris. mTLS for service-to-service APIs. See SP-030 API Security for the full architectural pattern."],"assumptions":"The application team uses a modern development stack with version control (Git), CI/CD pipelines, cloud infrastructure (AWS/GCP/Azure or self-hosted Kubernetes), and containerised deployments. The team has access to standard open-source security tooling. The organisation has identified which NIST 800-53 controls apply to their system.","typicalChallenges":"Developers perceive security controls as compliance overhead rather than engineering discipline. Security teams write policies in control framework language that developers cannot action. Gap assessments produce risk registers instead of engineering backlogs. Implementation guidance is generic and does not account for the specific technology stack. Security scanning tools generate noise that teams learn to ignore. The translation from control to implementation lives in tribal knowledge and informal documentation that becomes stale.","indications":"Engineering teams building cloud-native applications who need to satisfy security control requirements. Startups and scale-ups approaching their first security review or compliance certification. Development teams receiving audit findings that they cannot translate into engineering work. Organisations where security architecture exists on paper but implementation is inconsistent. Any team where the question 'how do I actually implement this control?' goes unanswered.","contraIndications":"Organisations with mature security engineering practices and established internal implementation guides. Legacy systems where infrastructure-as-code and CI/CD pipelines are not feasible without prior modernisation. Operational technology and embedded systems where the development model is fundamentally different from cloud-native application development.","threatResistance":"Addresses the implementation gap that allows controls to exist on paper without corresponding technical implementation. Reduces attack surface through automated baseline enforcement and drift detection. Prevents common vulnerability classes (injection, broken authentication, secrets exposure) through systematic input validation, standard auth patterns, and secrets management. Supply chain security through SBOM generation, dependency scanning, and provenance verification. CI/CD hardening prevents pipeline compromise and ensures artifact integrity."},"examples":{"AI Application Security Review (CharacterSphere Model)":["Developer building AI-powered application identifies SP-027 (Secure AI Integration) as the architectural pattern","SP-041 provides the implementation checklist: how to detect current security state, identify gaps, and close them","DETECT phase: run gitleaks on repo, scan dependencies with Trivy, audit API authentication, check container security","GAP phase: map findings to NIST controls, produce engineering backlog items not risk register entries","IMPLEMENT phase: work through backlog using SP-041 guidance per control area, verify with automated scanning"],"Startup First Security Review":["Pre-Series A startup needs SOC 2 readiness but has no security engineering function","SP-041 provides the practical implementation guide organised by developer concern rather than compliance framework","Engineering team implements secrets management, structured logging, dependency scanning, and pipeline security","Compliance mapping is derived from implementation (bottom-up) rather than controls driving implementation (top-down)","Auditor traces each control to concrete technical implementation rather than policy documents"],"Enterprise Audit Remediation":["Internal audit identifies 47 control gaps across application portfolio","Security team translates audit findings to SP-041 control areas, producing specific engineering tickets","Development teams use DETECT guidance to assess their own applications before remediation","IMPLEMENT guidance provides consistent approach across teams, reducing rework and inconsistency","Automated scanning in CI/CD pipelines provides continuous assurance against regression"],"Platform Engineering Security Baseline":["Platform team defines organisation-wide security baseline using SP-041 as the template","Golden path templates (Terraform modules, Helm charts, CI pipeline templates) encode control implementations","Application teams inherit security controls through platform abstractions rather than implementing individually","CIS benchmarks, container security, and pipeline gates enforced at platform layer","Control coverage measured automatically through platform telemetry rather than manual assessment"],"Developing Areas":["Secure-by-default framework adoption is accelerating, with memory-safe languages (Rust, Go, Swift) gaining traction for security-critical components. The US government (ONCD, CISA) has explicitly recommended migration away from memory-unsafe languages like C and C++. However, the existing codebase in C/C++ is measured in billions of lines, rewrite economics are prohibitive for most organisations, and the developer talent pool for Rust remains limited. The practical path for most teams is incremental adoption of memory-safe languages for new components rather than wholesale migration.","Runtime Application Self-Protection (RASP) effectiveness remains debated in the security community. RASP promises to detect and block attacks from within the application at runtime, but production deployments report performance overhead of 5-15%, high false positive rates for complex business logic, and difficulty distinguishing legitimate edge cases from attack patterns. The market is consolidating around fewer vendors, and most organisations that deploy RASP use it in monitoring mode rather than blocking mode, limiting its protective value.","Interactive Application Security Testing (IAST) adoption is growing as a middle ground between SAST (high false positives, no runtime context) and DAST (limited code coverage, slow feedback). IAST instruments the running application to observe data flow and detect vulnerabilities with runtime context, producing fewer false positives than SAST. However, IAST requires instrumentation agents that may not support all language runtimes, and coverage depends on test suite quality. The tool category is approximately 5 years behind SAST/DAST in ecosystem maturity.","Software composition analysis (SCA) accuracy is improving but still generates significant noise. The core challenge is determining whether a vulnerable dependency is actually reachable in the application's execution path -- a library may contain a vulnerable function that the application never calls. Reachability analysis is an emerging SCA capability that reduces false positives by 40-60% in early implementations, but it requires deep language-specific analysis that not all SCA tools support across all ecosystems.","AI-generated code security baseline is an urgent developing area as adoption of coding assistants (GitHub Copilot, Cursor, Claude) reaches 50%+ among professional developers. Studies show AI-generated code contains security vulnerabilities at rates comparable to human-written code, but the speed of generation means more vulnerable code reaches review faster. Establishing security scanning gates specifically for AI-assisted development -- mandatory SAST on all AI-generated suggestions, automated secret detection, and dependency validation -- is becoming a critical pipeline requirement that most organisations have not yet formalised."]},"references":[{"title":"CIS Benchmarks","url":"https://www.cisecurity.org/cis-benchmarks","note":"Industry-standard configuration baselines for cloud platforms, operating systems, containers, and databases. The practical implementation of CM-02/CM-06."},{"title":"OWASP Application Security Verification Standard (ASVS)","url":"https://owasp.org/www-project-application-security-verification-standard/","note":"Comprehensive application security requirements organised by verification level. Maps control requirements to testable assertions."},{"title":"SLSA (Supply-chain Levels for Software Artifacts)","url":"https://slsa.dev/","note":"Framework for ensuring the integrity of software artifacts throughout the supply chain. Practical implementation of SR-03/SR-04."},{"title":"CycloneDX SBOM Standard","url":"https://cyclonedx.org/","note":"OWASP standard for Software Bill of Materials. Supports SBOM, CBOM, VEX, and attestation formats."},{"title":"NIST SP 800-53 Rev 5 — Security and Privacy Controls","url":"https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final","note":"The control framework this pattern makes actionable. 191 controls mapped to practical developer implementations."},{"title":"Kubernetes Pod Security Standards","url":"https://kubernetes.io/docs/concepts/security/pod-security-standards/","note":"Three-tier pod security model (Privileged, Baseline, Restricted) implementing CM-07 and SC-07 for container workloads."},{"title":"Sigstore / Cosign","url":"https://www.sigstore.dev/","note":"Keyless signing and verification for software artifacts. Implements SI-07 and CM-14 for container images and build artifacts."},{"title":"OWASP Cheat Sheet Series","url":"https://cheatsheetseries.owasp.org/","note":"Practical implementation guidance for specific security topics. Complements the control-to-implementation mapping in this pattern."},{"title":"OpenSSF Scorecard","url":"https://securityscorecards.dev/","note":"Automated assessment of open source project security practices. Useful for dependency risk evaluation."},{"title":"Terraform Sentinel / OPA Rego","url":"https://www.openpolicyagent.org/","note":"Policy-as-code frameworks for enforcing infrastructure baselines. Implements CM-06 and CM-07 as automated gates."}],"relatedPatterns":["SP-027","SP-028","SP-030","SP-012"],"relatedPatternNames":["Secure LLM Usage","Secure DevOps Pipeline","API Security","Secure Software Development Lifecycle"],"threats":[{"id":"T-41-001","name":"Implementation gap — Security controls exist in policy documents but lack corresponding technical implementation, leaving the system unprotected despite paper compliance","mitigatedBy":["CM-02","CM-06","CA-07"]},{"id":"T-41-002","name":"Configuration drift — Infrastructure and application configurations diverge from declared baselines over time through manual changes, hotfixes, and undocumented modifications","mitigatedBy":["CM-02","CM-06","CM-03"]},{"id":"T-41-003","name":"Secrets exposure — Credentials, API keys, and cryptographic material committed to source code, embedded in container images, or stored in plaintext configuration files","mitigatedBy":["SC-12","SC-28","IA-05"]},{"id":"T-41-004","name":"Supply chain compromise — Malicious or vulnerable dependencies introduced through package managers, container base images, or CI/CD tooling without detection","mitigatedBy":["SR-03","SR-04","SA-04","SA-11"]},{"id":"T-41-005","name":"Injection attacks — SQL injection, NoSQL injection, command injection, and cross-site scripting through unvalidated user input reaching backend systems","mitigatedBy":["SI-10","SI-15","SC-08"]},{"id":"T-41-006","name":"Broken authentication — Custom or misconfigured authentication allowing session hijacking, credential stuffing, token theft, or privilege escalation","mitigatedBy":["AC-03","AC-06","IA-02","IA-08"]},{"id":"T-41-007","name":"Container escape and lateral movement — Containers running with excessive privileges enabling breakout to host, access to other workloads, or cluster compromise","mitigatedBy":["CM-07","SC-07","SI-07"]},{"id":"T-41-008","name":"Pipeline compromise — Attacker modifies CI/CD pipeline to inject malicious code, exfiltrate secrets, or deploy backdoored artifacts to production","mitigatedBy":["SA-11","CM-14","SI-07","SA-15"]},{"id":"T-41-009","name":"Insufficient logging — Security-relevant events not captured, logged in unparseable format, or not forwarded to monitoring, preventing detection and forensic investigation","mitigatedBy":["AU-02","AU-03","AU-06","AU-12"]},{"id":"T-41-010","name":"API abuse — Unauthenticated, unrate-limited, or improperly validated API endpoints exploited for data exfiltration, denial of service, or business logic manipulation","mitigatedBy":["SC-08","AC-04","SC-13","SI-10"]},{"id":"T-41-011","name":"Tribal knowledge dependency — Security implementation knowledge concentrated in individuals rather than codified in automation, creating single points of failure and inconsistent application across teams","mitigatedBy":["CM-02","SA-11","PL-02","SA-15"]},{"id":"T-41-012","name":"Compliance theatre — Organisation satisfies audit through manual evidence collection and point-in-time assessments rather than continuous automated verification, leaving security gaps between audit cycles","mitigatedBy":["CA-07","CA-02","AU-06","PM-14"]}],"controls":[{"id":"CM-02","name":"Baseline Configuration","family":"CM","emphasis":"critical"},{"id":"CM-06","name":"Configuration Settings","family":"CM","emphasis":"critical"},{"id":"CM-07","name":"Least Functionality","family":"CM","emphasis":"critical"},{"id":"SC-12","name":"Cryptographic Key Establishment and Management","family":"SC","emphasis":"critical"},{"id":"SI-10","name":"Information Input Validation","family":"SI","emphasis":"critical"},{"id":"SA-11","name":"Developer Testing and Evaluation","family":"SA","emphasis":"critical"},{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"important"},{"id":"AC-06","name":"Least Privilege","family":"AC","emphasis":"important"},{"id":"IA-02","name":"Identification and Authentication (Organizational Users)","family":"IA","emphasis":"important"},{"id":"IA-05","name":"Authenticator Management","family":"IA","emphasis":"important"},{"id":"IA-08","name":"Identification and Authentication (Non-Organizational Users)","family":"IA","emphasis":"important"},{"id":"SC-08","name":"Transmission Confidentiality and Integrity","family":"SC","emphasis":"important"},{"id":"SC-28","name":"Protection of Information at Rest","family":"SC","emphasis":"important"},{"id":"SC-07","name":"Boundary Protection","family":"SC","emphasis":"important"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"important"},{"id":"SI-07","name":"Software, Firmware, and Information Integrity","family":"SI","emphasis":"important"},{"id":"SI-15","name":"Information Output Filtering","family":"SI","emphasis":"important"},{"id":"SR-03","name":"Supply Chain Controls and Processes","family":"SR","emphasis":"important"},{"id":"SR-04","name":"Provenance","family":"SR","emphasis":"important"},{"id":"SA-04","name":"Acquisition Process","family":"SA","emphasis":"important"},{"id":"SA-15","name":"Development Process, Standards, and Tools","family":"SA","emphasis":"important"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"important"},{"id":"CM-14","name":"Signed Components","family":"CM","emphasis":"important"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"important"},{"id":"AU-03","name":"Content of Audit Records","family":"AU","emphasis":"important"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"standard"},{"id":"AU-12","name":"Audit Record Generation","family":"AU","emphasis":"standard"},{"id":"AC-04","name":"Information Flow Enforcement","family":"AC","emphasis":"standard"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"standard"},{"id":"CA-02","name":"Control Assessments","family":"CA","emphasis":"standard"},{"id":"PL-02","name":"System Security and Privacy Plans","family":"PL","emphasis":"standard"},{"id":"PM-14","name":"Testing, Training, and Monitoring","family":"PM","emphasis":"standard"}],"controlFamilySummary":{"CM":5,"SC":5,"SI":3,"SA":4,"AC":3,"IA":3,"AU":4,"SR":2,"CA":2,"PL":1,"PM":1}}}