githubEdit

6.5 Security

govstack-cfr-security2.0.0

#1 Enforce Transport Security (REQUIRED IMMUTABLE) (previously 5.12)

All communication is secured using HTTPS/TLS 1.3. Insecure cipher suites MUST be disabled. This supports protection against man-in-the-middle (MITM) attacks.

#2 Use Secure Configuration (REQUIRED IMMUTABLE) (previously 5.21)

All configuration uses secure methods, such as environment variables or a secret management system. Sensitive credentials are never be stored in source code or version control.

#3 Include Support for Capturing Logging information (REQUIRED IMMUTABLE) (previously 5.10)

Building Blocks MUST have a mechanism for generating logging information. This may be as simple as using STDOUT and capturing through docker logs, or may use other log sinking technologies.

#4 Security testing is completed before solution is shared for use by others. This must include coverage of high-risk vulnerabilities as described in globally recognized standards (e.g. OWASP Top 10). (REQUIRED IMMUTABLE)

#5 No sensitive data such as keys, certificates, or passwords is stored in code repositories or documentation. (REQUIRED IMMUTABLE)

Some blocks may require the use of security keys. Those that do must have clearly defined key rotation policies to enhance security

Building blocks SHOULD validate all incoming data to ensure that it conforms with the expected format and type. APIs should also sanitize incoming data, removing any unsafe characters or tokens.

#8 Only up-to-date and industry-accepted cryptographic algorithms MUST be used for data protection. (RECOMMENDED IMMUTABLE)

#9 Enforce Access Control and Authentication (REQUIRED EXTENSIBLE)

Each Building Block enforces a least-privilege access control model to ensure that users and services only access the resources they need. Authentication and authorization should be handled through an Identity and Access Management service using open standards. For user-facing flows, authenticate the user and obtain their roles/permissions via OpenID Connect. For client-to-client or machine-to-machine API interactions, authorize calls using OAuth 2.0 or JWT-based access tokens. Tokens are short-lived and stored securely, with regular rotation, and access decisions are logged to support auditing.

Where external APIs are exposed, a gateway layer handles:

  • rate limiting,

  • authentication and authorization,

  • request/response validation, and

  • encryption enforcement.

Security testing MUST be automated in CI/CD pipelines, including:

  • Static Application Security Testing (SAST),

  • Dynamic Application Security Testing (DAST), and

  • Dependency Vulnerability Scanning (e.g., OWASP Dependency-Check, Trivy).

  • Critical vulnerabilities MUST be addressed before release.

A compromise in one Building Block allows escalation or lateral movement to others. Containers and services run with minimal privileges (principle of least privilege). Network segmentation and namespace isolation is implemented.

#13 Logging and Monitoring Security Events (REQUIRED EXTENSIBLE)

Security events (e.g., failed logins, permission violations) are logged separately from functional logs. Logs integrate with centralized observability systems (see CFR Observability). All logs support audit trails with timestamping, trace IDs, and user context.

All source code undergoes peer code review focusing on security implications. Sensitive code segments (e.g., crypto, identity) are reviewed by qualified experts.

Each Building Block defines incident response and disaster recovery plans.

Procedures SHOULD include:

  • alerting and triage workflow,

  • root-cause analysis and postmortems,

  • secure rollback or hot patch mechanisms.

Building Blocks maintain documentation that demonstrates compliance with:

  • OWASP ASVS,

  • ISO/IEC 27001, and

  • GovStack Security Framework.

Periodic third-party audits are RECOMMENDED for production-grade deployments.

Last updated

Was this helpful?