Harjoittajan opas: Turvallisuus

Ensisijaiset mittarit:

• OpenSSF:n parhaiden käytäntöjen merkki
• Libyears
• Vapautustaajuus

Jos et ole jo lukenut Ammatinharjoittajan opas: Johdanto – Asioita, joita kannattaa miettiä mittareita tulkittaessa, keskeytä nyt ja lue tämä opas.

Turvallisuus on vain niin vahva kuin sen heikoin lenkki. Avoimen lähdekoodin ohjelmistopaketteja löytyy melkein kaikista käyttämistämme ohjelmistoista (Synopsis 2024), joten avoimen lähdekoodin projektiemme turvallisuudesta voi olla laajakantoisia vaikutuksia muihin projekteihin, käyttäjiimme ja laajempaan ekosysteemiin.

Turvallisuus voi olla tärkeä tekijä avoimen lähdekoodin projektien valinnassa, mutta minkä tahansa ohjelmistokomponentin turvallisuus on vain yhtä hyvä kuin sen riippuvuuksien turvallisuus (Imtiaz 2022). Turvallisuus on tärkeä näkökohta sekä valittaessa avoimen lähdekoodin komponentteja, joista projektisi riippuu, että vaikuttaessa siihen, miksi muut saattavat päättää käyttää (tai olla käyttämättä) avoimen lähdekoodin projektiasi. Tässä valinnassa on tärkeää huomata, että suositut paketit eivät ole enemmän tai vähemmän todennäköisesti hyviä tietoturvakäytäntöjä (Imtiaz 2022).

Vuoden 2024 Synopsys Open Source Security and Risk Analysis -raportissa todettiin, että 96 % heidän skannaamistaan ​​koodikannoista sisälsi avoimen lähdekoodin ohjelmistoja, ja valitettavasti 84 %:lla niistä oli haavoittuvuuksia (74 %:lla korkea vakavuusluokitus). Koska avointa lähdekoodia on kaikkialla, avoimen lähdekoodin projektiturvallisuus vaikuttaa projektiemme terveyteen ja kestävyyteen, mikä heijastuu koko ohjelmistoekosysteemiin. Muista kuitenkin, että turvallisuusriski voidaan usein ajatella todennäköisyyden ja vaikutuksen funktiona. Todennäköisyys on hyödynnettävyyden potentiaali, ja vaikutus on vahinko, joka voi aiheutua hyväksikäytöstä ohjelmiston käyttöönoton yhteydessä, joten riski on asia, joka jokaisen avoimen lähdekoodin käyttöönottajan on määritettävä omassa kontekstissaan, tilanteensa, ja ympäristö.

Koska turvallisuus on monimutkainen ja kriittinen aihe, tämä opas on tarkoitettu vain pääset alkuun matkallasi kohti projektisi turvallisuuden parantamista. Se on ei kattava opas kaikkeen, mitä sinun tarvitsee tietää avoimen lähdekoodin projektien turvallisuudesta. Practitioner Guide -sarjan tavoitteena on saada ihmiset läpi ylivoimaisen vaiheen, jonka monet kokevat, kun he kohtaavat monia uusia mittareita, jotka auttavat heitä löytämään tapoja ymmärtää ja parantaa projektiensa terveyttä. Kun olet aloittanut tämän harjoittajan oppaan käytön, voit oppia lisää linkeistä kattaviin oppaisiin alla olevassa Lisälukemista -osiossa ja linkitetyissä koko tässä oppaassa.

Vaihe 1: Tunnista trendit

Turvallisuus on monimutkainen aihe, mutta voit aloittaa tarkastelemalla muutamia keskeisiä mittareita. Ensinnäkin OpenSSF:n parhaiden käytäntöjen merkki kriteerit luo hyvän teknisen perustan, joka yhdistää perusturvakäytännöt. Toiseksi, kun käytät vanhentuneita riippuvuuksia, sinulla on neljä kertaa todennäköisemmin tietoturvaongelmia (Cox et al. 2015), joten käyttämällä Libyears metriikka voi auttaa sinua ymmärtämään, pidätkö riippuvuutesi ajan tasalla. Kolmas, Vapautustaajuus auttaa arvioimaan, ilmestyvätkö tietoturvakorjaukset ja muut päivitykset ajoissa, jotta käyttäjäsi voivat hyötyä tietoturvapäivityksistäsi.

OpenSSF:n parhaat käytännöt

- Open Source Security Foundation (OpenSSF) tarjoaa tapoja arvioida avoimen lähdekoodin projektiasi useilla eri ulottuvuuksilla saadaksesi yhteenvedon siitä, missä projektisi käytäntöjä voidaan parantaa. Vaikka turvallisuuskäytännöt ovat tärkeä osa, OpenSSF:n parhaiden käytäntöjen merkki ylittää pelkän turvallisuuden ja ehdottaa parhaita käytäntöjä projektillesi. Se on hyvä tapa paitsi arvioida tietoturvakäytäntöjäsi ja parantaa niitä tunnuksen kriteerien täyttämiseksi, vaan se myös viestittää käyttäjillesi, että noudatat OpenSSF:n parhaita käytäntöjä. Raportointi-, turvallisuus- ja analyysiosista löytyvät kriteerit soveltuvat parhaiten projektisi tietoturvan ymmärtämiseen ja parantamiseen.

Image Source: https://www.bestpractices.dev/en/projects/63

Libyears

- Libyears metriikka selittää riippuvuuksien iän, joihin luotat, verrattuna näiden riippuvuuksien nykyisiin vakaisiin julkaisuihin. Sitä ehdotettiin ensimmäisen kerran artikkelissa "Measuring Dependency Freshness in Software Systems" (Cox ym. 2015). Yleensä pienempi Libyear-luku on parempi, koska se osoittaa, että pidät riippuvuutesi ajan tasalla.

Image Source: https://github.com/nasirhjafri/libyear

Vertaamalla projektissasi käytetyn riippuvuuden nykyistä versiota kunkin riippuvuuden uusimpaan versioon, voit ymmärtää paremmin, missä sinun on ehkä oltava huolellisempi riippuvuutesi päivittämisessä. Tekninen viive riippuvuuksien päivittämisessä johtuu kuitenkin yleensä jännitteestä, joka vallitsee uusimman version käytön ja jo hyvin toimivan ratkaisun rikkomisen välillä, joten joissain tapauksissa kehittäjät voivat tarkoituksella käyttää vanhempaa versiota uusimman version sijaan. yhteensopivuusongelmiin tai muihin teknisiin ongelmiin (Zerouali et al. 2019).

Vapautustaajuus

On erittäin tärkeää, että tietoturvapäivitykset, virheenkorjaukset ja uudet ominaisuudet julkaistaan ​​ajoissa. Julkaisutiheyttä tarkasteltaessa on tärkeää ottaa mukaan isojen julkaisujen lisäksi myös kaikki pienet julkaisut, koska kiireelliset tietoturvakorjaukset julkaistaan ​​yleensä suurten julkaisujen ulkopuolella.

![Toistuvasti julkaistavan projektin julkaisutiheys][https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/releases.png?raw=true]

Muista, että tämän mittarin tulkitseminen voi olla haastavaa, koska erityyppiset projektit ja erilaiset tilanteet voivat vaikuttaa siihen, tarvitseeko projekti saada useammin vai harvemmin julkaisutahdin. Tasainen julkaisutiheys voi viitata vakaampaan tai kypsemmään projektiin.

Vaihe 2: Diagnoosi

Hyvä paikka aloittaa projektisi suojauskäytäntöjen mahdollisten ongelmien diagnosointi on aloittaa OpenSSF Project Badging Criteria -kriteerien käsittely. Kun se on käynnissä, se näyttää todennäköisesti tältä:

Image Source: https://www.bestpractices.dev/en/projects/40

Kuten aiemmin mainittiin, tämä sisältää turvallisuuden parhaita käytäntöjä, mutta myös yleisempiä ohjelmistosuunnittelun parhaita käytäntöjä projektin parantamiseksi monin eri tavoin. Jokaisen ehdotuksen alla on kysymyksiä, joihin sinun on vastattava tunnuksen saamiseen vaadittavilla kriteereillä.

Tässä on esimerkiksi muutamia turvallisuusosion kysymyksiä:

Päätät sitten tavoittaa tunnuksen tai et, kriteerit Varsinkin tietoturva- ja raportointiosioissa käytettyjä, ovat hyvä tapa pohtia, kuinka voisit ymmärtää ja parantaa projektisi turvallisuutta. On myös muita vaihtoehtoja tehdä turvallisuuden itsearviointeja projekteillesi, mukaan lukien itsearviointi, että CNCF käyttää projekteihinsa.

Diagnoosin seuraava vaihe saattaa olla Libyears-raporttisi tarkastelu keskittyen vanhentuneimpiin riippuvuuksiin. Kun käytät vanhentuneita riippuvuuksia, sinulla on neljä kertaa todennäköisemmin tietoturvaongelmia (Cox ym. 2015), joten riippuvuuksien pitäminen ajan tasalla on tärkeä tekijä projektin turvallisuuden parantamisessa. Kuten aiemmin mainittiin, riippuvuudelle on joskus hyviä syitä nykyisen version takana: rikkoutuneita muutoksia, yhteensopimattomuutta ohjelmistosi/muiden riippuvuuksien kanssa tai muita teknisiä ongelmia. Diagnoosi tässä tapauksessa vaatii harkitun ja perusteellisen tarkastelun, onko olemassa hyvä syy olla päivittämättä riippuvuutta.

Tarkistaaksesi, julkaisetko oikea-aikaisia ​​julkaisuja, sinun tulee tarkastella viimeisen vuoden aikana luomiasi tietoturvakorjauksia. Jos olet julkaissut jokaisen tietoturvakorjauksen aikana, olet todennäköisesti melko hyvässä kunnossa. Jos tietoturvakorjaukset ovat kasaantuneet eivätkä poistuneet julkaisusta, sinun pitäisi luultavasti tarkastella, miksi näin tapahtui, ja katsoa, ​​voitko parantaa julkaisuprosessiasi tehdäksesi julkaisuja useammin, kun korjaat haavoittuvuuksia.

Vaihe 3: Kerää tarvittaessa lisätietoja

Vaiheissa 1 ja 2 käytetyt esimerkit tarjoavat lähtökohdan, jota voidaan laajentaa käyttämällä lisätyökaluja ja mittareita. Hyvä seuraava askel diagnoosiprosessissa olisi myös suorittaa OpenSSF Scorecard, joka menee hyvin yksityiskohtaisesti tarkistuksiin, jotka auttavat sinua löytämään alueita, joilla projektisi saattaa olla haavoittuvainen lähdekoodin, koontiversion, riippuvuuksien, testauksen ja projektin ylläpitoluokkien osalta.

Saatat huomata, että tässä oppaassa ei ole mittaria, joka keskittyisi tietoturva-aukkojen ratkaisemiseen. Se on erittäin tärkeää, mutta haastavaa mitata, koska sinun on kyettävä erottamaan tietoturvaongelmat bugeista ja muista ongelmista ja samalla sitoa alkuperäinen haavoittuvuusraportti muutospyyntöihin, joissa korjaus tehtiin. On monia tapoja tehdä tämä, mutta kuinka teet sen, riippuu työkaluistasi. Vaikka se ei ehkä ole paras mittari aloittamiseen, sen mittaamista kannattaa harkita yhtenä seuraavista vaiheistasi. Alla olevat lisätiedot tarjoavat hyvän alun tämän mittaamiseen.

Lisätiedot:

• OpenSSF Scorecard (ei CHAOSS-mittari, vaan työkalu, joka kerää monia turvallisuusmittareita)
• Muuta pyyntöjä
• Vianratkaisun kesto
• SPDX-asiakirja
• Ylävirran koodiriippuvuudet

Vaihe 4: Tee parannuksia

Yksi parhaista paikoista aloittaa suojauskäytäntöjesi parantaminen on suojata koodivarasto. Tämä sisältää käyttöoikeuksien hallinnan, haaran suojauksen, lahjoitusten hallinnan ja paljon muuta. The OpenSSF-lähdekoodin hallintaalustan määritysten parhaat käytännöt oppaassa on luettelo ehdotuksista ja linkit niiden toteuttamiseen sekä GitHubille että GitLabille.

Toinen hyvä lähtökohta on luoda yksityiskohtainen suojauskäytäntöasiakirja projektillesi. Tämä löytyy yleensä a SECURITY.md tiedosto arkistosi juuressa. Tämän asiakirjan tarkoituksena on antaa ohjeita tietoturva-aukkojen ilmoittamiseen sekä dokumentoida, miten reagoit näihin raportteihin, mukaan lukien saartojen. Tämä asiakirja auttaa sinua täyttämään OpenSSF Best Practices Badgen raportointikriteerien vaatimukset. Yksityiskohtaiset ohjeet suojauskäytäntöjen luomiseen löytyvät monista paikoista, joten emme kopioi niitä täällä. Esimerkiksi, OpenSSF:n OSS-haavoittuvuusopas sisältää lisätietoja siitä, mitä tämän tiedoston tulisi sisältää, sekä malleja ja ohjeita suojauskäytännön toteuttamiseksi, mikä ylittää asiakirjan luomisen ja sisältää tietoja infrastruktuurista ja muista suojausprosessin hallinnan vaatimuksista.

Kuten mainittiin, kun käytät vanhentuneita riippuvuuksia, sinulla on neljä kertaa todennäköisemmin tietoturvaongelmia (Cox ym. 2015), joten riippuvuuksien pitäminen ajan tasalla on tärkeä tekijä projektin turvallisuuden parantamisessa. Riippuvuudet vaativat harkitun ja perusteellisen tarkastelun, onko olemassa hyvä syy olla päivittämättä riippuvuutta, sekä uudempien versioiden testaamista, jotta voit varmistaa, että et riko jotain muuta riippuvuutta päivittäessäsi. Vaikka on hyviä syitä välttää tiettyjen riippuvuuksien päivittämistä, useimmissa tapauksissa riippuvuuksia ei päivitetä, koska voi olla vaikeaa seurata, milloin ne pitäisi päivittää. Työkalu kuten Riippuvainen or Renovatebot voi auttaa tunnistamaan ja päivittämään automaattisesti tiettyjä riippuvuuksia.

Hyvä tietoturvakorjausten dokumentointi voi auttaa lisäämään tietoisuutta saatavilla olevista tietoturvakorjauksista (Imtiaz et al. 2022), ja on tärkeää varmistaa, että korjaukset saapuvat julkaisuun ajoissa. Jos teet tietoturvakorjauksia usein, mutta et saa niitä julkaisuun nopeasti, sinun pitäisi luultavasti selvittää, miksi näin tapahtuu ja voitko parantaa julkaisuprosessiasi tehdäksesi julkaisuja useammin, kun korjaat haavoittuvuuksia. On myös tärkeää, että julkaisutiedot tai muut asiakirjat sisältävät tietoja tietoturvakorjauksista korostaaksesi päivitysten tärkeyttä ohjelmistoasi käyttäville ihmisille.

Kuten aiemmin mainittiin, OpenSSF Best Practices -merkin kriteerien läpikäyminen on hyvä tapa tehdä tietoturvaparannuksia. The yksityiskohtainen näkymä kaikkien tasojen kriteerisivulta sisältää selitykset ja linkit lisätietoihin, jotka voivat auttaa sinua parantamaan jokaista näistä alueista.

Vaihe 5: Seuraa tuloksia

Koska turvallisuus on niin monimutkainen aihe, sitä voi olla vaikea valvoa. On kuitenkin joitain asioita, joita voit seurata ajan mittaan nähdäksesi, vaikuttavatko tietoturvaasi parantamisesi toimenpiteet. Tässä on muutamia ehdotuksia edistymisen seurantaan:

• OpenSSF Scorecard: Onko kokonaispisteesi parantunut? Oletko parantanut pisteitäsi joillakin yksittäisillä alueilla, jotka olet tunnistanut parannettavaksi?
• Libyears: Onko libyear-lukusi parantunut?
• Julkaisut: Luotko julkaisun aina, kun luot tietoturvakorjauksen?

Varoitukset ja huomiot

• Koska turvallisuus on kriittinen aihe, tämä opas on tarkoitettu vain pääset alkuun matkallasi kohti projektisi turvallisuuden parantamista. Se on ei kattava opas kaikkeen, mitä sinun tarvitsee tietää avoimen lähdekoodin projektien turvallisuudesta. Voit oppia lisää alla olevista linkeistä Lisälukemista.
• Saatat huomata, että tässä oppaassa ei ole mittaria, joka keskittyisi tietoturva-aukkojen ratkaisemiseen. Se on erittäin tärkeä, mutta haastava mitata, joten suosittelemme sisällyttämään tämän mittarin yhdeksi ensimmäisistä seuraavasta askeleesta. Katso vaiheesta 3 lisätietoja.

Lisälukeminen

• Meillä lyhyt video (<4 minuuttia) omistettu tälle oppaalle CHAOSS YouTube-kanavalla.
• CHAOSScast-jakso tästä oppaasta.
• OpenSSF:n verkkosivut sisältää laajan valikoiman erittäin yksityiskohtaisia ​​oppaita, koulutusta ja muita resursseja.
• - CNCF-tietoturvaohjeet asiakirja on paljon vähemmän kattava kuin OpenSSF-oppaat, mutta siitä voi olla apua, jos olet vasta aloittamassa tietoturvasi parantamista.
• OpenSSF:n OSS-haavoittuvuusopas sisältää oppaan, malleja ja runbookin, joka keskittyy tietoturvapolitiikan kehittämiseen ja toteuttamiseen.

Palaute

Haluaisimme mielellämme palautetta saadaksesi lisätietoja siitä, kuinka ihmiset käyttävät CHAOSS Practitioner -oppaita ja kuinka voimme parantaa niitä ajan myötä. Ole hyvä ja täytä tämä lyhyt kysely antaaksesi palautetta.

Osallistujat

Seuraavat ihmiset osallistuivat tähän oppaaseen:

• Dawn Foster
• Matt Germonprez
• Emily Fox

Viitteet

• Cox, J., Bouwers, E., Van Eekelen, M., & Visser, J. (2015, toukokuu). Riippuvuuden tuoreuden mittaaminen ohjelmistojärjestelmissä. sisään 2015 IEEE/ACM 37. IEEE International Conference on Software Engineering (Nide 2, s. 109-118). IEEE.
• Imtiaz, N., Khanom, A. ja Williams, L. (2022). Avoin vai ovela? nopea vai hidas? kevyt vai raskas?: Avoimen lähdekoodin pakettien tietoturvajulkaisujen tutkiminen. IEEE Transactions on Software Engineering, 49(4), 1540-1560.
• Synopsys (2024). Avoimen lähdekoodin tietoturva- ja riskianalyysiraportti.
• Zerouali, A., Mens, T., Gonzalez‐Barahona, J., Decan, A., Constantinou, E., & Robles, G. (2019). Muodollinen viitekehys teknisen viiveen mittaamiseksi komponenttivarastoissa – ja sen soveltaminen npm:ään. Journal of Software: Evolution and Process, 31(8), e2157.

CHAOSS Practitioner Guides -oppaat ovat MIT:n lisensoituja, eläviä asiakirjoja, ja otamme mielellämme palautteen ja palautteen. Voit ehdottaa muutoksia tähän asiakirjaan osoitteessa https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/security.md