Tarkista, mitä julkaisu sisältää

Selvitä riippuvuuden tarve

Agentti voi ehdottaa pakettia, joka näyttää ratkaisevan ongelman. Ehdotus ei osoita paketin olemassaoloa tai soveltuvuutta. Tarkista registry, julkaisija, paketin tarkka nimi ja versio ennen asennusta.

Kuvitteellisessa CSV-viennissä runtime voi jo tarjota tarvittavan toiminnan. Uusi paketti voi silti olla järkevä, mutta se lisää ylläpitovastuuta ja suorituspolkuja. Vertaa toteutustyötä riippuvuuden jatkuviin vastuisiin.

Tarkasta lisenssi ja tuettu runtime. Tutki ylläpitoa ja olennaisia advisory-tiedotteita. Tuttu nimi voi tarkoittaa toisessa registryssä eri pakettia. Onnistunut asennus osoittaa vain asennuksen valmistumisen.

Tarkasta asennus ja build

Riippuvuus voi suorittaa koodia asennuksen tai buildin aikana. Rajaa ympäristön credentialit ja verkkoyhteydet. Älä anna tuotantosalaisuuksia jobille, joka käsittelee epäluotettua PR:ää.

Käytä commitattua lockfilea, kun ekosysteemi tukee sitä. Vaadi buildia noudattamaan sitä. Tarkasta lockfile-muutokset lähdekoodin mukana, myös yllättävät transitiiviset paketit. Version lukitseminen auttaa toistettavuutta, mutta ei tee haavoittuvasta versiosta turvallista.

NISTin SSDF käsittelee ohjelmiston suojaamista ja kehityskäytäntöjä koko elinkaaressa. Sovella tätä laajempaa näkökulmaa build-ympäristön suunnitteluun. Lue viitekehys.

Erota komponenttiluettelo alkuperänäytöstä

Software bill of materials eli SBOM kuvaa ohjelmiston komponentteja. Se auttaa tunnistamaan julkaisut, joihin uusi komponenttiongelma vaikuttaa. Se ei itsenäisesti osoita komponenttien turvallisuutta.

Provenance kuvaa artefaktin tuottamista. SLSA määrittelee formaatin buildia ja sen syötteitä koskeville tiedoille. Tarkistuksen pitää yhdistää tieto luotettuun tuottajaan ja käytettävään artefaktiin. Pelkkä provenance-niminen tiedosto ei riitä. SLSA provenance.

Kirjaa vientipalvelulle tarkastettava ketju:

1. Tarkastettu commit yksilöi hyväksytyn lähdekoodin.
2. Build yksilöi syötteensä ja suoritusympäristönsä.
3. Artefaktilla on pysyvä digest.
4. Tarkistukset yksilöivät tutkimansa lähdekoodin tai artefaktin.
5. Deployment kirjaa kohdeympäristöön viedyn artefaktin.

Älä tee hyväksynnän jälkeen erilaista buildia ilman määriteltyä tarkistusmenettelyä. Muuttuva tagi, kuten latest, voi myöhemmin viitata eri imageen.

Arvioi löydöksen merkitys

Haavoittuvuuslöydös tarvitsee kontekstin: version, saavutettavan toiminnan, altistuksen, korjauksen ja seurauksen. Kirjaa mahdollisen väliaikaisen poikkeuksen perusteet. Nimeä omistaja, päättymisaika ja uuden tarkistuksen ehto.

Älä vaimenna koko scanneria yhden soveltumattoman löydöksen vuoksi. Epäonnistunut skannaus ei ole puhdas tulos. Timeout, tukematon paketti tai puuttuva advisory-feed tarkoittaa puuttuvaa näyttöä.

Suunnittele päivitykset myös julkaisun jälkeen. Uusi tiedote voi koskea eilen hyväksyttyä artefaktia. Palvelun omistaja tarvitsee komponenttiluettelon, reagointitavan ja kapasiteetin korjatun version julkaisemiseen.

Jatka haavoittuvuuksien hallintaan, jossa toistuvat skannaukset yhdistyvät tuotannossa varmennettuihin korjauksiin.