
# AI‑avusteinen vaatimustenmukaisuuden integrointi CI/CD-työnkulkuihin

Nykyisessä hyperkilpailullisessa SaaS‑maailmassa **nopeus** ja **luotettavuus** eivät ole enää erillisiä tavoitteita – niiden on kuluttava rinnakkain. Kehitystiimit julkaisevat koodia useita kertoja päivässä, kun taas turvallisuus‑ ja vaatimustenmukaisuustiimeiltä pyydetään edelleen kattavia auditointiapuja jokaisen merkittävän julkaisun jälkeen. Tämä kitka aiheuttaa pullonkauloja, viivästyttää kauppoja ja lisää epä‑vaatimustenmukaisuuden riskiä.

Tässä astuu mukaan **Procurize**, AI‑ohjattu alusta, joka keskittää turvallisuuskyselylomakkeet, politiikkadokumentit ja vaatimustenmukaisuustodisteet. Monet asiakkaat käyttävät jo Procurizea automatisoidakseen vastauksia ulkoisiin auditointeihin, mutta uusi raja‑alue nousee esiin: **tämän automaation upottaminen suoraan CI/CD‑putkiin (Continuous Integration / Continuous Deployment)**. Käsittelemällä vaatimustenmukaisuutta koodina ja hyödyntämällä reaaliaikaista AI‑avustusta organisaatiot voivat saavuttaa **jatkuvan turvallisuuden varmistuksen** – samoin kuin ne jo toteuttavat jatkuvan toimituksen.

Tämä artikkeli selittää, miksi vaatimustenmukaisuuden automaation integrointi CI/CD:hen on tärkeää, esittelee mahdollistavat arkkitehtoniset mallit ja tarjoaa vaiheittaisen toteutusoppaan, jossa on koodiesimerkkejä. Olitpa **DevSecOps‑johtaja**, **CISO** tai tuotepäällikkö, saat käytännön tiekartan, jonka avulla muunnat vaatimustenmukaisuuden post‑julkaisuluettelosta **aina‑päälle – suojariviksi**.

---

## Miksi perinteinen vaatimustenmukaisuus on pullonkaula

| Perinteinen lähestymistapa | AI‑integroitu CI/CD |
|----------------------------|----------------------|
| Manuaalinen kyselylomakkeen täyttäminen julkaisun jälkeen | Automaattiset, politiikka‑perusteiset vastaukset rakennushetkellä |
| Keskitetyn version päivitykset tapahtuvat neljännesvuosittain | Reaaliaikaiset politiikka‑päivitykset leviävät heti |
| Auditoijat pyytävät todistusaineistoa viikkoja julkaisun jälkeen | Todistusaineisto liitetään jokaisen rakennusartefaktin yhteyteen |
| Vaatimustenmukaisuus‑tiimi toimii portinvartijana, hidastaen toimitusta | Vaatimustenmukaisuus on jaettu vastuuksi, joka on sisäänrakennettu putkeen |

**Keskeiset kipupisteet**:

1. **Viive** – Turvallisuustodisteet tuotetaan usein viikkoja julkaisun jälkeen, mikä lisää regressioiden riskiä.  
2. **Inhimillinen virhe** – Manuaalinen politiikkavastausten kirjoittaminen johtaa epäjohdonmukaisuuksiin.  
3. **Kaksoiskappaleet** – Tiimit ylläpitävät erillisiä politiikkadokumentteja auditointeja ja sisäistä käyttöä varten.  
4. **Näkyvyyden puute** – Insinöörit näkevät vaatimustenmukaisuuden tilan harvoin ennen auditointipyyntöä.

Kun vaatimustenmukaisuus siirretään CI/CD‑virtaan, nämä ongelmat lievittyvät ja se muuttuu **ennakoivaksi, data‑pohjaiseksi toiminnaksi**.

---

## Keskeiset käsitteet: Politiikka koodina, AI‑luodut vastaukset ja todistusaineisto artefakteina

1. **Politiikka koodina** – Tallenna turvallisuuspolitiikat (esim. **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, **[ISO 27001](https://www.iso.org/standard/27001)**, **[GDPR](https://gdpr.eu/)**) versionhallittuun repositorioon (esim. Git). Jokainen politiikka ilmaistaan koneellisesti luettavassa muodossa (YAML/JSON), jonka työkalut voivat parsia.

2. **AI‑luodut vastaukset** – Procurize‑LLM‑moottori voi lukea politiikkamäärittelyt ja automaattisesti tuottaa tiiviit, auditointivalmiit vastaukset kyselylomakekohteisiin. AI myös arvioi luottamustasot, korostaen ne alueet, joissa ihmisen tarkistus on vielä tarpeen.

3. **Todistusaineisto‑artefaktit** – Rakennusprosessi tuottaa muuttumattomia todistuksia (esim. kokoonpanon tilannevedokset, pääsylokit, testiraportit). Procurize yhdistää nämä artefaktit luotuihin vastauksiin, luoden **yksikäsitteisen totuuden lähteen** auditointia varten.

Nämä kolme kerrosta muodostavat **jatkuvan vaatimustenmukaisuuden palautesilmukan**:

```
git push → CI‑putki → AI‑vastausten luonti → Todistusaineiston liittäminen → Vaatimustenmukaisuuden kojelaudan päivitys
```

---

## Arkkitehtoninen kaavio

Alla on korkean tason kaavio komponenttien välisestä vuorovaikutuksesta. Kaavio on esitetty pseudo‑graafisessa koodilohkossa, jotta artikkeli pysyy siirrettävänä.

```mermaid
graph LR
    A[Kehittäjä tekee koodikommitin] --> B["CI‑palvelin (Jenkins/GitHub Actions)"]
    B --> C["Politiikkarepositorio (Git)"]
    B --> D["Rakenne‑ & testausvaihe"]
    D --> E["Luo todistusaineisto‑artefaktit"]
    C --> F["Procurize‑politiikkamoottori (API)"]
    E --> G["Procurize‑AI‑vastauspalvelu (API)"]
    F --> G
    G --> H[Vaatimustenmukaisuuden metadata‑tietokanta]
    H --> I[Vaatimustenmukaisuuden kojelauta / auditoinnit]
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style I fill:#bbf,stroke:#333,stroke-width:2px
```

**Komponentit**:

- **Politiikkarepositorio** – Keskitetty Git‑repo politiikkamäärittelyille (`policies/`‑kansio).  
- **CI‑palvelin** – Suorittaa rakennuksen, testauksen ja käynnistää vaatimustenmukaisuuden vaiheet.  
- **Todistusaineiston generaattori** – Skriptit, jotka tuottavat JSON/YAML‑todistukset (esim. `evidence/aws-iam.json`).  
- **Procurize‑API** – Kaksi pääpistettä:  
  - `/policies` politiikkojen lataamista tai hakemista varten.  
  - `/answers` todistusaineiston lähettämistä ja AI‑luotujen vastausten vastaanottoa varten.  
- **Vaatimustenmukaisuuden metadata‑tietokanta** – Kevyt tietokanta (esim. DynamoDB), joka kirjaa jokaisen rakennuksen vaatimustenmukaisuustilan.  
- **Kojelauta** – Olemassa oleva Procurize‑käyttöliittymä tai räätälöity näkymä, joka näyttää vaatimustenmukaisuuden perjulkaisun.

---

## Vaihe‑vaihe – toteutusopas

### 1. Valmistele politiikkarepositorio

Luo Git‑repo (tai alirepositorio), jossa tallennat jokaisen vaatimustenmukaisuuskirjon YAML‑tiedostona.

```yaml
# policies/soc2.yaml
framework: SOC 2
controls:
  - id: CC6.1
    description: "Datan salaus tallennuksissa"
    requirement: "Kaikkien tuotantodatan on oltava salattu käyttäen AES‑256‑salausta."
    evidence_type: "Encryption Configuration"
  - id: CC6.2
    description: "Datan salaus siirrossa"
    requirement: "TLS 1.2+ on pakotettava kaikelle ulkoiselle liikenteelle."
    evidence_type: "TLS Configuration"
```

Commit‑aa repo, suojaa `main`‑haara – vain vaatimustenmukaisuustiimi saa merge‑oikeudet. Kehittäjät hakivat viimeisimmät politiikat CI‑vaiheessa.

### 2. Lisää CI‑vaihe todistusaineiston keräämiseen

Esimerkki GitHub Actions -määrityksestä, jossa testauksen jälkeen kerätään todistusaineisto.

```yaml
name: CI
on:
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run unit tests
        run: npm test

  collect-evidence:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Export AWS IAM policy snapshot
        run: |
          aws iam get-account-authorization-details > evidence/aws-iam.json
      - name: Export TLS config
        run: |
          grep -i 'tls' /etc/nginx/nginx.conf > evidence/tls-config.txt
      - name: Upload evidence as artifact
        uses: actions/upload-artifact@v3
        with:
          name: compliance-evidence
          path: evidence/
```

Tämä työ luo `evidence/`‑kansion JSON‑ tai tekstitiedostoilla, jotka vastaavat politiikan `evidence_type`‑kenttiä.

### 3. Kutsu Procurize‑AI‑vastauspalvelua

Kirjoita pieni skripti (`procurize-submit.sh`), joka lukee todistusaineiston, kutsuu Procurize‑API:a ja tallentaa AI‑luodut vastaukset JSON‑tiedostoon.

```bash
#!/usr/bin/env bash
set -euo pipefail

API_KEY="${PROCURIZE_API_KEY}"
POLICY_REPO="https://github.com/yourorg/compliance-policies.git"
EVIDENCE_DIR="evidence"

# Hae viimeisimmät politiikat (valinnainen, jos politiikat eivät ole jo checkoutissa)
git clone "$POLICY_REPO" policies_tmp
tar -czf policies.tar.gz -C policies_tmp .

# Kutsu Procurize‑vastaus‑API:a
curl -s -X POST "https://api.procurize.com/v1/answers" \
  -H "Authorization: Bearer $API_KEY" \
  -F "policies=@policies.tar.gz" \
  -F "evidence=@${EVIDENCE_DIR}" \
  -o answers.json

# Tallenna vastaukset CI‑artefaktiksi myöhempää käyttöä varten
jq . answers.json > compliance/answers-${GITHUB_SHA}.json
```

Lisää CI‑vaihe, jossa skripti ajetaan ja vastaukset tallennetaan artefaktiksi.

```yaml
  generate-answers:
    needs: collect-evidence
    runs-on: ubuntu-latest
    env:
      PROCURIZE_API_KEY: ${{ secrets.PROCURIZE_API_KEY }}
    steps:
      - uses: actions/checkout@v3
      - name: Download evidence artifact
        uses: actions/download-artifact@v3
        with:
          name: compliance-evidence
          path: evidence/
      - name: Run Procurize submission script
        run: ./procurize-submit.sh
      - name: Upload answers artifact
        uses: actions/upload-artifact@v3
        with:
          name: compliance-answers
          path: compliance/
```

### 4. Tallenna vaatimustenmukaisuuden metadata

Käytä kevyt Lambda‑funktiota (tai serverless‑funktiota), joka käynnistyy artefaktien tallennuksen yhteydessä, jäsentää `answers.json`‑tiedoston ja kirjoittaa rivin DynamoDB‑tauluun.

```python
import json, boto3, os

ddb = boto3.resource('dynamodb')
table = ddb.Table(os.getenv('COMPLIANCE_TABLE'))

def handler(event, context):
    # Oletetaan S3‑tapahtuma, jossa objektin avain on answers‑JSON
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    obj = s3.get_object(Bucket=bucket, Key=key)
    answers = json.loads(obj['Body'].read())

    record = {
        'build_id': answers['metadata']['build_id'],
        'status': 'COMPLIANT' if answers['overall_confidence'] > 0.9 else 'REVIEW_NEEDED',
        'timestamp': answers['metadata']['timestamp'],
        'summary': answers['summary']
    }
    table.put_item(Item=record)
    return {'statusCode': 200}
```

Nyt jokaisesta rakennuksesta on DynamoDB‑tietue, joka on nähtävissä Procurize‑kojelaudassa tai omassa UI:ssa.

### 5. Pakota portti (valinnainen)

Jos haluat, että putki **epäonnistuu** matalan luottamustason vuoksi, lisää viimeinen vaihe, joka tarkistaa DynamoDB:n tilan ja lopettaa työn.

```yaml
  compliance-gate:
    needs: generate-answers
    runs-on: ubuntu-latest
    steps:
      - name: Check compliance status
        run: |
          STATUS=$(aws dynamodb get-item \
            --table-name ${{ secrets.COMPLIANCE_TABLE }} \
            --key '{"build_id": {"S": "${{ github.sha }}"}}' \
            --query 'Item.status.S')
          if [[ "$STATUS" != "COMPLIANT" ]]; then
            echo "Compliance gate failed: $STATUS"
            exit 1
          fi
```

Kun portti läpäistään, artefakti jatkaa tuotantoon. Jos se epäonnistuu, kehittäjät saavat välittömästi palautetta ja voivat korjata politiikkakuilut ennen julkaisua.

---

## Saavutetut hyödyt

| Mittari | Perinteinen prosessi | Integroitu CI/CD‑prosessi |
|---------|----------------------|---------------------------|
| Keskimääräinen kyselylomakkeen läpimenoaika | 10–14 päivää | 2–4 tuntia |
| Manuaalinen työmäärä per julkaisu | 12–20 h | ≤ 2 h (pääosin tarkistus) |
| Auditointitodisteiden kattavuus | 70‑80 % | 95‑100 % |
| Vaatimustenmukaisuuteen liittyvien julkaisukilpailujen määrä | 1 per sprintti | < 0,1 per sprintti |

Nopeuden lisäksi integraatio **vähentää riskiä**, koska jokainen commit tarkistetaan viimeisimpiin politiikkoihin, ja **parantaa auditointikykyä** kiinteiden todistusten liittämisen avulla jokaiselle rakennukselle.

---

## Yleisiä sudenkuoppia – ja miten ne vältetään

1. **Vanha politiikkavälimuisti** – Varmista, että CI‑job hakee aina viimeisimmän politiikkarepositorion. Käytä tarkistussummaa tai checksum‑tarkistusta tuoreuden varmistamiseksi.  
2. **Liiallinen riippuvuus AI:sta** – Aseta AI‑palvelu merkitsemään kaikki vastaukset, joiden luottamusprosentti on alhaisempi kuin esim. 85 %. Ihmisen on tarkistettava nämä kohdat.  
3. **Todistusaineiston koon kasvu** – Säilytä todistusaineisto pakatussa muodossa ja poista vanhat artefaktit säilytysaikapolitiikan mukaisesti.  
4. **API‑avainten turvallisuus** – Säilytä Procurize‑tunnistetiedot CI‑salaisuusvarastossa (esim. GitHub Secrets, Azure Key Vault). Kierrätä avaimet säännöllisesti.

---

## Mallin laajentaminen: CI‑stä CD‑hallintaan

Kun vaatimustenmukaisuus on sisällytetty **CI**‑vaiheeseen, samaa suojarakennetta voidaan viedä **CD**‑ (julkaisun) ja **runtime**‑valvontaan:

- **Julkaisun aikainen politiikkavalvonta** – Ennen Helm‑kaavion julkaisua ajetaan politiikka‑koodin tarkistus, joka validoi Kubernetes‑RBAC‑, verkon‑ ja salaisuus‑politiikat samojen YAML‑määrittelyjen perusteella kuin rakennusvaiheessa.  
- **Ajoaikainen todistusaineiston virtaus** – Käytä agenteja (esim. Falco, OpenTelemetry) lähetääkseen jatkuvasti turvallisuustapahtumia Procurize‑todistusaineistoon, sulkien silmukan **jatkuvalle vaatimustenmukaisuudelle**.  
- **Itsepalvelu‑vaatimustenmukaisuuden portaali** – Tarjoa asiakkaille luku‑vain‑näkymä vaatimustenmukaisuuskokoulusta, muuttaen vaatimustenmukaisuuden kilpailuetuksi.

---

## TL;DR

- Tallenna kaikki turvallisuuspolitiikat Git‑repoon **politiikka‑koodina** (YAML/JSON).  
- Lisää CI‑vaihe, joka **kerää muuttumattoman todistusaineiston** ja lähettää sen Procurize‑**AI‑vastaus‑API:lle**.  
- Tallenna AI‑luodut vastaukset ja luottamustasot metadata‑tietokantaan.  
- Käytä **vaatimustenmukaisuuden porttia**, joka estää julkaisut, joiden luottamus on liian alhainen.  
- Saavuta lähes reaaliaikainen auditointivalmius, vähennä manuaalista työtä ja nopeuta markkinoille pääsyä.

Integroimalla Procurize‑AI:n vaatimustenmukaisuuden automaation CI/CD‑työnkulkuusi, muutat vaatimustenmukaisuuden satunnaiseksi tarkastukseksi **jatkuvaksi, automatisoiduksi suojaksi** – samoin kuin moderni DevOps käsittelee testauksen, turvallisuuden ja observabiliteetin.

---

## Katso myös

- [NIST CSF –integraatio CI/CD‑putkiin (NIST SP 800‑53)](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)  
- [GitHub Actions secure software supply chain -opas](https://github.com/github/securitylab)  
- [Microsoft Azure Policy as Code -opas](https://learn.microsoft.com/azure/governance/policy/)