SOC 2 -alustasi näyttää, että kontrolli toimii. CRACI tallentaa, mitä buildi sisälsi.

Järjestely, josta tämä sivu kertoo

Moni SaaS-tiimi päätyy samaan järjestelyyn. Syftin tai Trivyn kaltainen generaattori tuottaa SBOM:n CI:ssä, haavoittuvuusskanneri valvoo repositorioita, ja compliance-automaatioalusta liitetään GitHubiin ja pilvitiliin keräämään näyttöä SOC 2:ta varten. Se toimii. Auditoijat hyväksyvät sen, eikä kukaan vietä auditointia edeltävää viikkoa kuvakaappauksia ottaen.

Nämä alustat ovat tässä hyviä. Vanta kertoo, että se "connects read-only to your cloud, identity, code, and device tools" ja "automatically pulls evidence, maps it to controls," ja yli 1 200 automaattista testiä ajetaan tunneittain. Drata liittyy palveluihin "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" kerätäkseen näytön ja kohdistaakseen sen SOC 2 -kontrolleihin. Jos tavoite on puhdas SOC 2 -raportti, se on oikea työkalu.

Tämä sivu käsittelee kapeampaa kysymystä: mitä tuo näyttö kertoo itse SBOM:sta.

Mitä SOC 2 -tarkistus oikeasti kysyy

SOC 2 -tarkastukset raportoivat AICPA:n Trust Services Criteria -kriteereitä vasten. SBOM:eja lähinnä oleva kriteeri on CC7.1:

"To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities."

AICPA, 2017 Trust Services Criteria, CC7.1

Kriteeri kuvaa lopputuloksen. Menetelmä ja sen taustalla olevan komponentti-inventaarion syvyys jäävät sinun ja auditoijasi päätettäviksi. Siksi automaattinen testi kysyy yleensä, onko kontrolli käytössä ja toiminnassa: onko skanneri liitetty, ajettiinko se ja käsiteltiinkö löydökset käytäntösi mukaisesti. Se on reilu kysymys, ja se on se rasti.

Tarkistus ei kysy, luetteliko skannauksen taustalla oleva SBOM kaiken, mitä julkaisu sisälsi. Haavoittuvuutta, joka on komponentissa, jota SBOM ei koskaan luetellut, ei voi yhdistää mihinkään, joten skannaus näyttää puhdasta ja kontrolli näkyy yhä vihreänä.

Missä vihreä tarkistus ja täydellinen SBOM eroavat

SBOM-generaattorit työskentelevät edessään olevien tiedostojen pohjalta, ja niiden oma dokumentaatio näyttää, missä siihen jää aukkoja:

• expressjs/express 5.2.1 ei sisällä commitoitua lukitustiedostoa (lockfile), joten generaattorilla, joka selvittää riippuvuudet lukitustiedostoista, ei ole mitään selvitettävää. Se voi silti palauttaa dokumentin, jossa on muuta sen tunnistamaa, kuten GitHub Actions ja työnkulkutiedostot, mutta ei yhtäkään package.json:ssa ilmoitetuista npm-riippuvuuksista.
• Eri generaattorit palauttavat samasta checkoutista eri listat, koska kukin päättää itse, mikä lasketaan komponentiksi. GitHubin riippuvuusgraafin vienti on vielä kauempana: se rakentuu siitä, mitä GitHub tietää repositoriosta, ja lukee oletushaaraa eikä kiinnitettyä committia.
• NTIA:n toimittajakenttä jää tyhjäksi useimmissa dokumenteissa, koska useimmilla generaattoreilla ei ole sille lähdettä.

Mikään näistä työkaluista ei ole rikki. Kukin luki tiedostot, joihin se ohjattiin, ja kukin tuotti kelvollisen dokumentin standardimuodossa aikataulussa. Compliance-testin kannalta kontrolli toimi. SBOM ei silti kuvannut ohjelmistoa.

Mitä CRACI lisää näyttöön

CRACI korvaa GitHub Actions -runnerin. Vaihdat runs-on-arvoksi craci, ja ajot näkyvät yhä GitHubin käyttöliittymässä. SBOM tuotetaan tuon runnerin sisällä buildin aikana: pakettitietoinen välityspalvelin (proxy) havainnoi liikennettä pakettilähteisiin, joten tallenne kertoo, mitä jobi haki, eikä sitä, mitä tiedoston mukaan sen pitäisi hakea.

Kattavuus ilmoitetaan, sitä ei oleteta

Jokainen jobi ja jokainen välimuisti saa yhden viidestä kattavuustilasta: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded. Riippuvuusnäyttö kulkee välimuistien mukana, joten lämpimästä välimuistista palautetut paketit siirtyvät eteenpäin sen sijaan, että ne putoaisivat huomaamatta pois. Kun tallenne on vajaa, se kertoo sen.

Tämä vastaa standardien suuntaa. CISA:n ja sen kumppanien vuoden 2026 SBOM minimum elements pyytää SBOM:ien laatijoita "explicitly state whether the information is unknown to the SBOM author" sen sijaan, että kentät jätettäisiin hiljaa tyhjiksi.

Näyttö muodoissa, jotka auditoijat hyväksyvät

SBOM:t viedään CycloneDX- tai SPDX-muodossa, ja mukana ovat niiden komponenteista löydetyt haavoittuvuudet. Julkinen REST API palauttaa SBOM:n, jobin verkkojäljen ja alkuperätiedot, joten samat tallenteet voivat mennä sinne, missä auditointinäyttösi on.

Inventaario siitä, mitä on käytössä missäkin

CRACI:n inventaarionäkymä näyttää tarkasti, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa maailmanlaajuisesti. Kun uusi haavoittuvuus ilmenee, näet, missä tuotteissa ajetaan haavoittuvaa versiota, eikä sitä tarvitse koota julkaisutiedotteista ja taulukoista.

Pidä SOC 2 -alusta

CRACI ei ole compliance-automaatioalusta eikä korvaa sellaista. Se ei hallinnoi käytäntöjä, käyttöoikeuskatselmointeja, laitetarkistuksia tai toimittajakyselyjä. Ne vastaavat eri kysymyksiin. Compliance-alustasi näyttää, että kontrolli on olemassa ja toimii. CRACI tallentaa, mitä buildi haki mukaansa ja onko tuo tallenne täydellinen.

Ero kasvaa, kun myyt ohjelmistoja EU:hun. EU:n kyberkestävyyssäädös (Cyber Resilience Act, CRA) edellyttää, että valmistajat tunnistavat ja dokumentoivat komponentit muun muassa laatimalla ohjelmistojen materiaaliluettelon yleisesti käytetyssä ja koneluettavassa muodossa, joka kattaa vähintään tuotteiden ylimmän tason riippuvuudet (liitteen I osa II). Liite VII sijoittaa SBOM:n tekniseen dokumentaatioon ja antaa markkinavalvontaviranomaiselle oikeuden pyytää sitä. SOC 2 -raportti todistaa, miten organisaatiosi toteuttaa kontrollejaan. CRA:n edellyttämä SBOM kuvaa tiettyä tuotetta. CRA-katsauksemme kertoo aikataulusta, ja CRA-vaatimustenmukaisuuden sivu kertoo, mitä CRACI automatisoi. CRACI automatisoi merkittävän osan toimitusketjun näkyvyydestä ja näytöstä, jota laajempi CRA-vaatimustenmukaisuuden prosessi tarvitsee; se ei yksinään tee sinusta vaatimustenmukaista.

Sama näyttö palvelee myös ISO 27001:tä ja NIS2:ta. Katso SBOM:t ISO 27001:n, SOC 2:n ja NIS2:n näyttönä, kontrolli kontrollilta.

Näin kokeilet koskematta auditointiisi

1. Valitse yksi repositorio, jonka SBOM jo syöttää SOC 2 -näyttöäsi.
2. Ohjaa sen julkaisutyönkulku CRACI:lle vaihtamalla runs-on-arvoksi craci.
3. Vertaa tallennettua SBOM:ia nykyään tuottamaasi komponentti komponentilta ja tarkista jobin kattavuustila.
4. Päätä, kuuluuko ero näyttöösi.

Voit lukea lisää SBOM-generoinnista buildin aikana ja CRA-näytöstä tai katsoa, miten dokumentoimme omat kontrollimme tietoturvasivullamme.