ID: S202606011433
Status: school
Tags: avans 2-4, avans 2-4 LU2, avans 2-4 software security en compliance les, CICD

avans 2-4 sscl2 hardening ci-cd

⇐ Les ⇒

Title

DOE GOEDE COMMIT MESSAGES

Terugblik

• Niet gelogd is niet gebeurt
• Compliant-by-design

Lesstof:

Veritasium mentioned when talking about insider-threats:

2e Veritasium video in mijn lesstof vandaag lol, de andere was in avans 2-4 sdkl6 metrieken en testbaarheid

Secure CI-CD

Secure DevOps:

DevSecOps?

Evolutie na de ‘revolutie’ van devops

Fase	Verandering
DevOps	Dev + Ops samenwerken; CI/CD automatiseert build & deploy
+ Quality Gates	Geautomatiseerde checks voorkomen ‘oepsies’ in productie
DevSecOps	Security wordt een gedeelde verantwoordelijkheid van het hele team (‘shift left’)
Meetbaar & aantoonbaar	Logs, alerts, reviews en pipeline-rappotages = bewijs

Security ‘shift left’ Beveiliging wordt zo vroeg mogelijk in de SDLC ingebracht — niet pas bij de pentest.

SDLC fase	Security act.	Tooling
Plan / Design	Threat modeling	STRIDE, OWASP Threat Dragon, Iridius Risk*
Code	Secure coding standards, secrets-beheer	Linters, git-hooks
Build	SAST, dependency check	CodeQL, Snyk, OWASP Dependency-Check
Test	DAST, integratie-security tests	OWASP ZAP
Release	SBOM genereren, artifact signing	CycloneDX, Sigstore/Cosign
Deploy	Omgevingsscheiding, least privilege	GitHub Environments
Operate	Monitoring, alerting, patch management	SIEM

CI-CD pipeline

• Continuous Integration
  • elke commit (pull request) triggert een build + test
• Continuous Delivery
  • alleen gevalideerde code gaat door naar productie

NEN-7510:2024 controls

Gekopieert uit de slides met AI image to text.

8.4 & 8.32 | Broncode & change mgmt

“Wie mag wat aanraken — en hoe bewijsbaar is dat?”

Eis:

• Toegang tot broncode is beperkt. Alle wijzigingen zijn traceerbaar naar een natuurlijk persoon

Maatregelen:

• MFA verplight voor alle GitHub-accounts (ook admins)
• RBAC: niet elke ontwikkelaar heeft admin-rechten op elk repo
• Protected branches (master/release): alleen via Pull Request
• Minimaal 1 code review verplight
• Alle CI-checks moeten slaan vóór merge
• Force-push en directe deletes geblokkeerd — ook voor admins
• Branch ruleset: geldt voor iedereen zonder uitzonderingen
• Signed commits (optioneel maar aanbevolen): cryptografisch bewijs van auteur + PGP
• Audit log in GitHub: wie heeft wanneer wat gewijzigd

8.8 | Beheer van techn. vulns

“Weet wat er in je software zit — en houd het bij”

Eis:

• Kwetsbaarheden worden tijdig geidentificeerd, beoordeeld en verholpen.

Tooling:

Tool/Maatregel	Wat doet het?
SAST	Analyseer broncode op bekende kwetsbaarheden vóór compilatie — CodeQL, Semgrep
SCA	Controleert third-party dependencies op CVE’s — Dependabot, Snyk, OWASP Dependency-Check
SBOM	Inventaris van alle componenten + versies — CycloneDX of SPDX format
Patch mgmt	Harde deadlines op basis van CVSS-score én kritiekheid van het systeem

Patch-prioriteit (richtlijn):

• CVSS 9–10 (Critical): ≤ 24 uur
• CVSS 7–8.9 (High): ≤ 1 week
• CVSS 4–6.9 (Medium): volgende sprint
• CVSS < 4 (Low): geplande release

CVSS?

• Common Vulnerability Scoring System
• Standaard framework om de ernst van beveiligingsproblemen in te schatten op een schaal van 0 tot 10.
• De score wordt bepaald op basis van een aantal factoren, o.a.:
  • hoe het probleem kan worden misbruikt (aanvalsvector)
  • hoe moeilijk dat is
  • of toegang nodig is
  • wat de gevolgen zijn voor beveiliging, integriteit en beschikbaarheid (CIA)

8.9 | Configuratriebeheer

“De pipeline zelf is ook software — moet dus beveiligd worden”

Eis:

• Configuraties worden beheerd, gedocumenteerd en beschermd tegen ongeautoriseerde wijziging.

Maatregelen:

• Pipeline-as-code: GitHub Actions workflows staan in de repo (.github/workflows/)
• Versiebeheerd, reviewable, auditable
• Quality gates
  • Pipeline blokkeert bij falen van checks (Build → Unit tests → SAST → SCA → (DAST) → review → deploy)
• Secrets management
  • Nooit hardcoded in code of workflow-bestanden
  • Gebruik GitHub Secrets / Environment Secrets (niet direct leesbaar)
• Immutable artifacts
  • Een gebouwde artifact (JAR, container image) wordt niet achteraf gewijzigd;
  • Een fix = nieuwe build

8.25 | Beveiliging tijdens ontwikkelen

“Security by design: van eerste commit tot productie”

• Secure coding standards gedefinieerd en afgedwongen
  • zie 8.28
• Threat modelling in de designfase
  • b.v. STRIDE of PASTA
• Omgevingen zijn gescheiden
  • zie 8.31
• AuthN & AuthZ als expliciete ontwerpeis
  • NIET “we voegen het later toe”
• Safe defaults
  • systeem is standaard veilig geconfigureerd

8.29 | Testen (security focus)

“Security by design: van eerste commit tot productie”

• SAST in de CI-pipeline
  • elke commit
• Dependency Review bij elke PR
  • blokkeer nieuwe kwetsbare deps
• DAST in de acceptatieomgeving
  • b.v. OWASP ZAP
• Beveiligingstest-resultaten worden opgeslagen als pipeline-artifact
  • = bewijs
• Penetratietest bij releases
  • Bij voorkeur door specialisten

8.28 | Safe coding

“Vastgestelde richtlijnen zorgen voor veilig coderen — en dit wordt gecontroleerd”

Eis:

• Er gelden vastgestelde richtlijnen voor veilig coderen en deze worden gecontroleerd.

Maatregelen:

• Coding standards gedocumenteerd
  • b.v. OWASP Secure Coding Practices
• Linters afdwingen stijl en security-patronen
  • Java/Maven: SpotBugs, PMD, Checkstyle
  • In GitHub Actions: falen bij violations
• Secrets-beheer in code
  • Nooit API-keys, wachtwoorden of tokens in code of .env bestanden in de repo
  • GitHub Secret Scanning detecteert per ongeluk ge-committe secrets
  • Pre-commit hooks als extra vangnet (b.v. ‘detect-secrets’)
• Dependency pinning: gebruik exacte versienummers en hashes
  • Niet ‘latest’

8.31 | Scheiding van omgevingen (OTAP)

Omgeving	Doel	Data
Ontwikkel	Lokaal / feature branches	Gesynthetiseerde data
Test	Geautomatiseerde tests	Gegenereerde / geanonimiseerde data
Acceptatie	Functionele validatie + UAT	Gepseudonimiseerde data
Productie	Live systeem	Echte patiëntdata

Harde regels:

• Productiedata gaat nooit naar een lagere omgeving
• Systemen uit verschillende omgevingen communiceren nooit met elkaar
• Gebruik stubs/mocks voor third-party services in test/acceptatie
• Gescheiden secrets per omgeving (GitHub Environments)

8.33 | Testdata

• Realistische tests vereisen realistische data — maar niet echte data
• Pseudonimisering is technisch moeilijk goed te krijgen
  • Correlatie van velden maakt de-anonimisering mogelijk
  • GenAI is ‘best wel’ goed in correleren…
• Gebruik testdata-generatoren
  • b.v. Synthea voor medische data
• Gevoelige data z.s.m. verwijderen uit testomgevingen na gebruik

8.16 | Monitoring van de pipelines

“De pipeline is ook een aanvalspoppervlak”

Eis:

• Activiteiten worden gelogd en gecontroleerd op afwijkingen.

Wat monitoren in een CI/CD Context?

• Failed pipeline runs
  • Patroon van mislukte builds kan sabotage of fout signaleren
• Gebruik van secrets
  • Wie heeft wanneer een secret opgevoegd?
• Wijzigingen in workflow-bestanden
  • (.github/workflows/)
  • Direct een alert
• Deployment events
  • Wie heeft wat naar welke omgeving deployed en wanneer?
• Integriteit van artifacts
  • Hash van build-output opslaan en verifiëren bij deploy
• Beheersaccounts
  • Alert bij gebruik van admin-rechten buiten kantoorlijden

Tooling?

• GitHub Security tab + Dependabot alerts
• GitHub Audit Log
  • Exporteerbaar naar SIEM
• Notifications / webhooks
  • Naar Slack/Teams voor kritieke events

5.23 | Beveiliging cloud services

“GitHub is een clouddienst”

• Vastleggen welke clouddiensten gebruikt worden
  • en met welk doel!
• Toegang tot GitHub beheerd via organisatie-accounts
  • Geen persoonlijke accounts
• SSO / SAML koppeling met organisatie-IdP
  • b.v. Azure AD (Entra) (voor dit project optioneel)
• Data-retentiebeleid:
  • Hoe lang pipeline-logs en artifacts bewaren?
• Alle bovenstaande punten vastleggen!

5.30 | BCM

“Business Continuity Management”

(voor dit project even minder relevant)

• Wat als GitHub onbereikbaar is?
• Backup-strategie voor de repository (mirror naar eigen infra)
• Disaster recovery procedure: hoe ga je weer live na een incident?
• Wie mag een rollback uitvoeren?
• Hoe snel moet het systeem beschikbaar zijn?
  • RTO: hoe snel (Return Time Objective)
  • RPO: wat kunnen we missen (Return Point Objective)
• CI/CD-pipeline zelf is onderdeel van het continuïteitsplan

Tooling and tips

GitHub Security tooling

Feature	Wat het doet	NEN-7510
Branch Protection / Rulesets	Afdwingen van PR + reviews + checks	8.4, 8.32
Secret Scanning	Detecteert ge-committe secrets	8.28
CodeQL	SAST — vindt security-bugs in code	8.8, 8.29
Dependabot Alerts	CVE-melding bij kwetsbare deps	8.8
Dependabot Security Updates	Automatische PRs voor patches	8.8
Dependency Review Action	Blokkeert PRs met nieuwe kwetsbare deps	8.8, 8.29
GitHub Environments	OTAP met approval-gates en gescheiden secrets	8.31
Audit Log	Wie deed wat wanneer in de org	8.4, 8.16
SBOM export	Dependency-inventaris (CycloneDX/SPDX)	8.8

GitHub tips

Denk na over de inrichting

• Maak een organisatie aan
• Maak gebruik van projecten
• Richt issues / tickets / backlog goed in
• Richt…
• Doe dit NU, dan heb je er het meeste profijt van. Docs o.a.:
  • https://docs.github.com/en/organizations
  • https://docs.github.com/en/enterprise-cloud@latest/code-security/getting-started/github-security-best-practices
  • https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets
• Best wel veel werk. Verdeel het dus binnen je project (preview de handelingen ook!)

Note: de ‘action’ configuraties op de volgende zijn ter illustratie en niet geldig!

OpenMRS: Java / Maven stack

• Modules worden gebouwd als .omod-bestanden (OSGi bundles)
• SAST voor Java / Maven:

name: Initialize CodeQL
uses: github/codeql-action/init@v3
with:
  languages: java
 
name: Build with Maven
run: mvn -B package --no-transfer-progress
 
name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v3

• SCA voor Maven:

- name: Dependency Review
  uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: high

• SBOM genereren:

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    format: cyclonedx-json
    output-file: sbom.cyclonedx.json
 
- name: Upload SBOM as artifact
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.cyclonedx.json

OTAP in GitHub (environments)

main branch → [CI checks] → Deploy to TEST
                           (automatisch na geslaagde checks)
                           ↓
                           Deploy to ACCEPTATIE
                           (vereist: handmatige goedkeuring)
                           ↓
                           Deploy to PRODUCTIE
                           (vereist: 2 approvers + tijdvenster)

Per omgeving:

• Eigen secrets (database-wachtwoorden, API-keys — nooit gedeeld tussen omgevingen)
• Protection rules: wie mag goedkeuren, tijdvenster (bijv. alleen kantooruren voor productie)
• Audit trail: elke deployment gelogd met actor, tijdstip en versie

GitHub → NEN-7510

Github-maatregel	NEN-7510 control	Bewijs
MFA verplight voor alle accounts	8.4, 8.5	Org-instelling screenshot
Branch protection + required reviews	8.4, 8.32	Ruleset-configuratie
CodeQL in CI	8.8, 8.29	Pipeline-run rapport
Dependabot alerts + updates	8.8	Alert-overzicht
Dependency Review Action op PR’s	8.8, 8.29	PR-check log
Secret Scanning actief	8.28	Security tab
SBOM gegenereerd als artifact	8.8	Report in GitHub Actions
Environments met protection rules	8.31	Environment-configuratie
Secrets per environment gescheiden	8.31, 8.33	Environment secrets screenshot
GitHub Audit Log	8.16, 8.4	Exporteerbaar log
README met beleid en procedures	8.9, 8.25	README.md in repo

Opdrachten

Opdracht 1 | OTAP inrichten

Met de projectgroep

Doel: Een aantoonbaar geharde CI/CD-omgeving voor het OpenMRS-project.

Stappen:

• Maak minimaal test en productie omgevingen aan
  • Gescheiden configuratie, gescheiden secrets
  • Als docker gebruikt wordt kan dit met docker-compose bestanden
• Configureer GitHub Environments (minimaal test + productie)
  • Protection rules + approval-gates
• Richt de NEN-7510 controles in (zie checklist volgende slide)
• Schrijf een README.md die beschrijft:
  • Hoe de omgevingen zijn ingericht
  • Hoe voorkomen wordt dat testdata in productie terechtknomt
  • Hoe een nieuwe ontwikkelaar onboarded

Een nieuwe ontwikkelaar moet met alleen de README aan de slag kunnen.

Opdracht 1 | Checklist

Minimale eisen voor een aantoonbaar compliant pipeline

• Branch protection actief op main — alleen via PR’s verplight
• Alle CI-checks slaan vóór merge (build, test, SAST)
• CodeQL of gelijkwaardige SAST actief (bijv. Snyk)
• Secret Scanning actief
• Dependabot alerts + security updates actief
• Dependency Review Action gekoppeld aan PR’s
• SBOM wordt gegenereerd (CycloneDX of SPDX formaat) en geanalyseerd (SCA)
• GitHub Environments gedefinieerd met protection rules
• Secrets zijn gescheiden per environment
• Pipeline-artifacts (rapporten, SBOM) worden bewaard
• README.md beschrijft beleid en procedure (= mini-ISMS)

Opdracht 2 | Compliance verslag

Met de projectgroep

Doel: Aantonen dat de pipeline compliant is.

(opdracht 1 hoeft nog niet 100% gereed te zijn)

Schrijf een compliance verslag met:

• Per relevante NEN-7510:2024-2 control:

  • Wat de control vereist (korte beschrijving)
  • Hoe de pipeline hieraan voldoet (met verwijzing naar concrete instelling/bestand/screenshot)
  • Welk restricto er nog is (wat is nog niet geïmplementeerd en waarom)

• Structuur:

  • Tabel of genummerde secties per control

• Gebruik de controles uit slide 9 als basis

• Oplevering:

  • Markdown of Word document, ingeleverd via de repo.

---

References

• dit is de slides van deze les
• dit is een plek met behulpzame videos
• Relevant Veritasium video: https://youtu.be/aoag03mSuXQ?si=jQjYUyYxkGDtDyfc