Check Python Version Consistency / Check Python Version (push) Waiting to run

Details

docs(security): komplett sikkerhetsdokumentasjon med 7 manifestfiler

- SECURITY.md: Overordnet visjon med lenker til alle manifestfiler
- SECURITY_AUDITS.md: Historikk og To-Do liste
- RUNBOOK.md: 6 operasjonelle scenarier (ukjent bruker, eksponert secret, 401/403, 50x, VPC-SC, BinAuthz)
- INCIDENT_RESPONSE.md: PICERL-modell med eskaleringsmatrise
- SECRET_MANAGEMENT.md: Policy + lokal utvikling
- ACCESS_CONTROL.md: IAM-policy med service account-oversikt
- COMPLIANCE.md: TYR, Binary Auth, KMS-attestasjon

Opprydding:
- Slettet sensitive filer (test_secret.txt, final-secret-test.txt, tyr/certs/ca_password.txt)
- Slettet engangsskript og midlertidige filer
- Oppdatert .gitignore med *.txt

2026-09-04 08:25:57 +00:00

3.2 KiB

Raw Blame History

OSVxCC Compliance Framework

Dette dokumentet beskriver rammeverket og de tekniske kontrollene som sikrer at OSVxCC-arkitekturen er i samsvar med interne sikkerhetspolicyer. Målet er å kunne verifisere og attestere sikkerhetsstillingen kontinuerlig.

Komponenter i Compliance-rammeverket

Rammeverket består av tre hovedpilarer som jobber sammen for å skape en sikker forsyningskjede (secure supply chain).

1. TYR (Compliance-skanner)

Funksjon: TYR er et spesialutviklet verktøy som skanner GCP-prosjektets konfigurasjon mot et sett med forhånds-definerte sikkerhetsregler.
Regelsett (eksempler):
- Ingen GCS-buckets skal være offentlig tilgjengelige.
- Ingen primitive roller (editor, owner) skal være tildelt service accounts.
- Nødvendig logging (Data Access, Admin Activity) skal være aktivert.
- VPC Service Controls skal være aktivert for prosjektet.
Integrasjon: TYR kjøres som et obligatorisk steg i CI/CD-pipelinen (Cloud Build). En feil i TYR-skanningen stanser deployeringen.

2. Binary Authorization (BinAuthz)

Funksjon: En GCP-tjeneste som håndhever at kun verifiserte og attesterte container-images kan deployes til våre kjøremiljøer (Cloud Run, GKE).
Policy: En streng policy er aktivert som krever at alle images må ha en gyldig attestering fra en klarert attestor (se under) før de kan kjøres.

3. KMS Attestor (via TYR)

Funksjon: TYR fungerer som en "attestor". Når en CI/CD-pipeline har passert alle tester, skanninger og TYR-sjekker, utfører TYR en siste handling: den signerer container-imagets "digest" (en unik hash) med en privat nøkkel lagret i Google Cloud KMS.
Attestering: Denne signaturen fungerer som en attestering – et kryptografisk bevis på at imaget har bestått alle kvalitets- og sikkerhetssjekker.

Forsyningskjede-flyt (CI/CD)

graph TD
    A[Developer pusher kode] --> B{Cloud Build Pipeline};
    B --> C[1. Kjører enhetstester];
    C --> D[2. Bygger container-image];
    D --> E[3. Kjører sårbarhetsskanning];
    E --> F{4. Kjører TYR Compliance Scan};
    F -- Suksess --> G[5. TYR attesterer image med KMS-nøkkel];
    F -- Feil --> H[Pipeline stopper!];
    G --> I{6. Deploy til Cloud Run};
    I --> J[7. Binary Authorization verifiserer attestering];
    J -- Gyldig --> K[✅ Deployert!];
    J -- Ugyldig --> L[❌ Deployering blokkert!];

OBS: Hvis en pipeline feiler på grunn av TYR eller Binary Authorization (steg F eller J), se RUNBOOK.md for detaljerte feilsøkingsprosedyrer.

Andre Kontroller

VPC Service Controls: Perimeteren tyr_perimeter er en fundamental compliance-kontroll som teknisk håndhever data-isolering og forhindrer dataeksfiltrasjon, uavhengig av IAM-policyer.
Audit Logging: Admin Activity og Data Access logs samles inn og lagres for å gi en komplett revisjonsspor for all aktivitet i prosjektet.

Rapportering og Revisjon

TYR-rapporter: Hver kjøring av TYR genererer en rapport som lagres for fremtidig revisjon.
GCP Security Command Center: Brukes for å få en oversikt over potensielle sårbarheter og feilkonfigurasjoner som oppdages av innebygde skannere.

3.2 KiB Raw Blame History Unescape Escape