fuchsbau

Organisationen #10: Investments Unlimited, Helen Beal et al.

(back to books)

---

• Substrat: Set up compliance-as-code
  • security and compliance are product features
  • "break class": procedure for a person without access privileges to get access
  • "shift left": bring software testing as far forward ("left") as possible
• goal: define minimally acceptable release approach
  • objective #1: enforce peer reviews of code that is pushed to prod
  • objective #2: identify and enforce minimum quality gates
  • objective #3: remove (elevated) access to prod as much as possible
• automate compliance through compliance-as-code
  • "policies" (e.g. ">1 code reviewer") provide specifics for "controls" (e.g. "peer review")
  • policy examples:
    • peer review must be done by one person other than the code author
    • no software releases are allowed with a known critical vulnerability
    • unit test code coverage for new code must be at least 60% for a new release
• OSCAP and OPA ("Open Policy Agent") are standards to define security controls
• SBOM ("software bill of materials"): list of primary and transitive dependencies
  • industry is aligning on the CycloneDX and SPDX standard formats for SBOMs
  • issue with open source: possible that nobody keeps track of security vulnerabilities
• preventive & detective controls
  • preventive: prevent something bad from moving forward (e.g. quality gate in CI/CD)
  • detective: validate a system is still in compliance (e.g. with a SBOM)
• audit outline: what we say we do ("promises") and what we actually do
• evidence store: log database for CI/CD pipeline steps
• software budget: track deficits in quality, risk, compliance, audit; take action if exceeded