Suunnitelmasta auditointivalmiiksi: sovellusturvallisuusvaatimusten hallinta ISO 27001:n, DORA:n ja NIS2:n näkökulmasta

Auditointia edeltävä jännitys oli käsin kosketeltavaa. Marialle, keskisuuren fintech-yhtiön tietoturvajohtajalle, tuleva DORA-vaatimustenmukaisuuden arviointi ei tuntunut niinkään katselmoinnilta vaan tilinteolta. Hänen tiiminsä oli osaava ja infrastruktuuri kovennettu, mutta yksi sitkeä haavoittuvuus valvotti häntä öisin: organisaation sovellusten laaja ja kaoottinen kokonaisuus.

Viimeisin huolenaihe oli uusi asiakasrajapinnan maksupportaali, joka oli kiirehditty markkinoille neljännesvuositavoitteiden saavuttamiseksi. Kehitystiimi työskenteli tiukan ketterän mallin mukaisesti ja oli täyttänyt kaikki toiminnalliset vaatimukset. Kun Marian tiimi teki alustavan skannauksen, tulokset vahvistivat hänen pelkonsa.

Portaalista puuttuivat vahvat istunnon aikakatkaisusäännöt, sen syöttökentät olivat alttiita perustason injektiohyökkäyksille ja virheilmoitukset paljastivat arkaluonteisia järjestelmätietoja. Kyse ei ollut kehittyneistä zero-day-haavoittuvuuksista, vaan perustavanlaatuisista suunnitteluvirheistä. Juurisyy oli kiusallisen selvä. Tietoturvavaatimuksia ei ollut koskaan muodollisesti määritelty, dokumentoitu tai integroitu kehityssprintteihin. Tiimillä oli epämääräinen toimeksianto “tehdä siitä turvallinen”, mutta ilman konkreettista suunnitelmaa tietoturva jäi epäselväksi ja usein sivuutetuksi jälkiajatukseksi.

Tämä tilanne ei ole poikkeus. Se korostaa kriittistä kuilua, jonka monet tietoturvajohtajat ja vaatimustenmukaisuudesta vastaavat henkilöt kohtaavat: miten aikomus “teemme tietoturvaa” muutetaan eksplisiittisiksi ja testattaviksi sovellusturvallisuusvaatimuksiksi, jotka ovat linjassa keskeisten standardien, kuten ISO/IEC 27001:2022, sekä merkittävien säädösten, kuten NIS2, DORA ja GDPR, kanssa.

Epäselvyyden korkea hinta: mitä vaatimustenmukaisuus tosiasiassa edellyttää

Marian ongelman ydin on yleinen organisatorinen epäonnistuminen: tietoturvaa käsitellään laatuominaisuutena eikä joukkona velvoittavia vaatimuksia. Vaikuttava tietoturvavaatimus on täsmällinen, mitattava ja testattava. “Sovelluksen on oltava turvallinen” on toive. “Sovelluksen on toteutettava 15 minuutin käyttämättömyyteen perustuva istunnon aikakatkaisu, validoitava kaikki käyttäjän syöttämä tieto ennalta määritettyä merkistöä vasten ja salattava kaikki siirrettävä tieto TLS 1.3:lla” on vaatimus. Juuri tätä selkeyttä auditoijat etsivät ja kehittäjät tarvitsevat turvallisten ohjelmistojen rakentamiseen.

Ilman sitä seurauksena on epäonnistumisten ketju:

• Epäyhtenäinen toteutus: Eri kehittäjät tulkitsevat sanan “turvallinen” eri tavoin, mikä johtaa hallintakeinojen tilkkutäkkiin ja vaikeasti ennakoitaviin aukkoihin.
• Kasvavat korjauskustannukset: Suunnitteluvirheen löytäminen ja korjaaminen tuotannossa on moninkertaisesti kalliimpaa kuin sen käsittely suunnitteluvaiheessa.
• Auditointipoikkeamat: Auditoijat tunnistavat nopeasti, jos tietoturvavaatimusten määrittelylle ei ole jäsenneltyä prosessia, mikä johtaa merkittäviin havaintoihin.
• Liiketoimintariski: Jokainen määrittelemätön vaatimus on mahdollinen hyökkäysvektori, joka altistaa organisaation tietomurroille, taloudellisille menetyksille ja mainehaitalle.

Nykyaikaisissa standardeissa odotus on johdonmukainen: tietoturva on määriteltävä vaatimuksina varhaisessa vaiheessa ja kytkettävä riskiin ja lainsäädäntöön. ISO/IEC 27002:2022 -ohjeistus hallintakeinosta 8.26, Application security requirements, edellyttää, että organisaatiot määrittävät, dokumentoivat ja hyväksyvät tietoturvavaatimukset järjestelmällisesti muodollisen riskien arvioinnin ja sääntelyvaatimusten perusteella.

Tämä yksi periaate on keskeinen nivelkohta monelle vaatimustenmukaisuusvelvoitteelle. Clarysecin vaatimustenmukaisuuden yhteiskartoitus oppaassa Zenith Controls: The Cross-Compliance Guide Zenith Controls osoittaa, miten sama käsite esiintyy kaikkialla:

• GDPR Articles 25 ja 32 edellyttävät “sisäänrakennettua tietosuojaa” ja “käsittelyn turvallisuutta”.
• NIS2 Article 21(2)(d)-(e) korostaa turvallista kehittämistä ja toimitusketjun tietoturvaa.
• DORA Articles 6(4), 8, 10 ja 11 edellyttävät ICT-riskien hallintaa ja sisäänrakennettua tietoturvaa finanssialan toimijoilta.
• NIST SP 800-53 Rev.5 hallintakeinoissa SA-4 ja SA-15 edellyttää määriteltyjä järjestelmätason tietoturvavaatimuksia ja turvallisen kehityksen käytäntöjä.
• COBIT 2019 prosesseissa BAI03 ja DSS05 edellyttää, että tietoturvaan liittyvät vaatimukset yhdenmukaistetaan liiketoiminnan ja vaatimustenmukaisuuden kanssa ennen ratkaisun rakentamista.

Tavoitteena on määritellä Zenith Blueprint: An Auditor’s 30-Step Roadmap -oppaan Zenith Blueprint sanoin “mitä tietoturva tarkoittaa sovelluksillenne, ennen kuin riviäkään koodia kirjoitetaan.”

Miksi perinteiset lähestymistavat epäonnistuvat: tarkistuslistat, myöhäinen testaus ja tietoturvateatteri

Useimmat organisaatiot tekevät jo jonkinlaista sovellusturvallisuustyötä. Ongelma on, että se on harvoin rakennettu tavalla, joka kestää ISO/IEC 27001:2022 -sertifioinnin tai sääntelyvalvonnan tarkastelun.

Yleisiä epäonnistumismalleja ovat:

1. Yleisluonteiset tarkistuslistat: Tiimit käyttävät samaa yhden sivun “turvallisen ohjelmoinnin tarkistuslistaa” kaikissa projekteissa. Sitä ei ole kytketty sovelluksen erityisiin riskeihin, tietojen arkaluonteisuuteen tai sääntelykontekstiin. Kun auditoija kysyy, miten tarkistuslista vastaa GDPR Article 25:n vaatimuksia, selkeää vastausta ei ole.
2. Tietoturva myöhäisenä porttina: Tietoturvavaatimuksia ei sisällytetä suunnitteluun tai käyttäjätarinoihin. Ne ilmestyvät lopussa penetraatiotestipyyntönä. Zenith Blueprint varoittaa, että “projektin lopussa käytettävään tietoturvatarkistuslistaan luottaminen ei toimi; vaatimusten on muovattava arkkitehtuuria, vaikutettava kirjastovalintoihin ja ohjattava ominaisuuksien priorisointia ensimmäisestä päivästä lähtien.”
3. Ei jäljitettävyyttä vaatimuksesta testiin: Vaatimus “salata siirrettävät tiedot” voi olla olemassa, mutta siihen ei ole liitetty testitapausta, joka varmentaa TLS-version pakottamisen, varmenteen voimassaolon ja salausalgoritmien vahvuuden. Zenith Blueprint korostaa, että odotusten on oltava mitattavia ja testattavia, ja tietoturvatestit on kartoitettava suoraan vastaaviin vaatimuksiin.
4. Kolmannen osapuolen koodin ad hoc -käsittely: Nykyaikaiset sovellukset on usein “koottu yhteen sisäisestä koodista, kolmannen osapuolen kirjastoista, ohjelmointirajapinnoista ja pilvinatiiveista palveluista”, kuten Zenith Blueprint toteaa. Ilman eksplisiittisiä vaatimuksia toimittajille ja avoimen lähdekoodin komponenteille toimitusketjuriski jää valtavaksi ja hallitsemattomaksi sokeaksi pisteeksi.

Tuloksena on tietoturvateatteri: asiakirjoja on olemassa ja testejä suoritetaan, mutta kun vakavasti otettava auditoija tai valvoja etsii yhtenäistä vaatimustarinaa, koko prosessi hajoaa.

Perustan rakentaminen: politiikasta käytäntöön

Kurinalainen lähestymistapa sovellusturvallisuuteen alkaa selkeästä hallinnosta. Politiikka ei ole pelkkää byrokratiaa; se on virallinen totuuden lähde, joka antaa tiimeille valtuudet toimia ja tarjoaa auditoijille selkeän johdon tahdonilmaisun. Clarysecissä suunnittelemme politiikkoja, jotka ovat sekä velvoittavia että käytännöllisiä.

Meidän Sovellusturvallisuusvaatimusten politiikka Sovellusturvallisuusvaatimusten politiikka määrittää ehdottomat perussäännöt. Esimerkiksi kohdassa 5.2 otsikon ‘Hallinnointivaatimukset’ alla edellytetään:

Kaikille sovelluksille on tehtävä tietoturvavaatimusten validointi suunnittelun tai hankinnan aikana, ja sovellusturvallisuustiimin dokumentoitu hyväksyntä on hankittava.

Tämä yksinkertainen määräys estää “rakennetaan ensin, turvataan myöhemmin” -ajattelutavan. Politiikka myös määrittää selkeän vastuun. Kohta 4.3.1 otsikon ‘Roolit ja vastuut’ alla toteaa, että kehittäjien odotetaan:

Toteuttavan sovellukset määriteltyjen tietoturvavaatimusten ja standardien mukaisesti.

Tämä siirtää tietoturvan painopistettä erilliseltä ja usein vastapuoleksi koetulta tietoturvatiimiltä ohjelmiston tekijöille itselleen. Lisäksi politiikka yhdistää eri tietoturva-alueet toisiinsa. Kohta 10.2 viittaa integraatioon muiden keskeisten hallintakeinojen kanssa:

P4 – Pääsynhallintapolitiikka. Määrittää identiteetin- ja istunnonhallinnan standardit, jotka kaikkien sovellusten on toteutettava, mukaan lukien vahva tunnistautuminen, vähimpien oikeuksien periaate ja käyttöoikeuskatselmointien vaatimukset.

Pienemmille organisaatioille räätälöity politiikka, kuten Sovellusturvallisuusvaatimusten politiikka – pk-yritys Sovellusturvallisuusvaatimusten politiikka – pk-yritys, varmistaa, että nämä periaatteet ovat skaalattavissa. Se tunnistaa, että vaikka riskit ovat samankaltaisia, toteutuksen on oltava käytännönläheinen. Molemmat versiot tähtäävät lopulta samaan lopputulokseen: sovellusturvallisuus integroidaan täysimääräisesti ISMS:ään ja se on valmis auditointia varten.

Käytännön tiekartta: auditointivalmiiden sovellusturvallisuusvaatimusten rakentaminen

Politiikka määrittää “mitä” ja “miksi”, mutta kehittäjät ja projektipäälliköt tarvitsevat “miten”. Jäsennelty toteutusohje on välttämätön, jotta ylätason hallintakeinot voidaan muuntaa konkreettisiksi toimenpiteiksi. Zenith Blueprint -oppaan vaihe 21, joka keskittyy ISO/IEC 27002:2022 hallintakeinoon 8.26, tarjoaa selkeän kuusivaiheisen menetelmän.

Käydään prosessi läpi Marian maksupportaalia esimerkkinä käyttäen.

Vaihe 1: Aloita riskistä ja sääntelykontekstista

Hyödyntämällä ISO/IEC 27005:2024 -standardin mukaisen riskien arvioinnin tuotosta ja riskien käsittelyä tunnistat ensin kontekstin:

• Sovellus: asiakkaan itsepalveluna käytettävä maksupportaali.
• Tiedot: henkilötiedot, tunnistetiedot, maksutokenit.
• Lainkäyttöalueet: EU, finanssipalvelut, pilvipalvelussa ylläpidetty.
• Säädökset: GDPR, DORA, PCI DSS.

Zenith Controls -oppaan hallintakeinoa 8.26 koskevan ohjeistuksen ja siihen liittyvien ISO-standardien (27034-1, 27017, 27701) perusteella perustason vaatimusluokkiin on sisällyttävä tunnistaminen ja todennus, valtuutus, tietojen luokittelu, syötteen validointi, lokitus sekä siirrettävien ja levossa olevien tietojen suojaus.

Vaihe 2: Luo tai ota käyttöön tietoturvavaatimusten malli

Zenith Blueprint suosittelee vakioidun mallin luomista, jotta jokainen projekti vastaa samoihin perustaviin tietoturvakysymyksiin. Tästä asiakirjasta on tehtävä osa projektin käynnistystyökalupakkia.

Vähimmäisosiot ovat:

• Sovelluksen nimi, omistaja ja kriittisyys.
• Tietoluokat ja arkaluonteisuustasot.
• Sovellettavat sääntely- ja sopimusvelvoitteet (GDPR, DORA jne.).
• Uhkaympäristöä koskevat syötteet (johdettu hallintakeinosta 5.7 Uhkatiedustelu).
• Täsmälliset tietoturvavaatimukset luokittain (todennus, lokitus jne.).
• Yhteydet käyttäjätarinoihin ja hyväksymiskriteereihin.
• Yhteydet testitapauksiin (toiminnallinen testaus, tietoturvatestaus, penetraatiotestaus).
• Toimittajia ja kolmannen osapuolen komponentteja koskevat vaatimukset.

Vaihe 3: Sisällytä vaatimukset ketteriin artefakteihin

Tietoturvavaatimukset on sisällytettävä suoraan käyttäjätarinoihin ja hyväksymiskriteereihin. Marian portaaliprojektin “asiakkaan rekisteröityminen” -eepoksessa tämä tarkoittaa yksinkertaisen toiminnallisen tarinan muuttamista tietoturvatietoiseksi.

• Alkuperäinen käyttäjätarina: “Uutena käyttäjänä voin luoda käyttäjätilin.”
• Turvallinen käyttäjätarina: “Uutena asiakkaana haluan luoda turvallisen käyttäjätilin, jotta maksutietoni ovat suojattuja.”
• Hyväksymiskriteerit (sisäänrakennetulla tietoturvalla):
  • Järjestelmän on toteutettava vahva salasanapolitiikka P4 – Pääsynhallintapolitiikka -politiikan mukaisesti.
  • Järjestelmän on edellytettävä sähköpostivarmennusta kertakäyttöisen linkin kautta ennen käyttäjätilin aktivointia.
  • Käyttäjätilin luontilomake on suojattava CAPTCHA-mekanismilla bottihyökkäysten estämiseksi.
  • Kaikki rekisteröitymisyritykset on kirjattava lokiin lähde-IP-osoitteella ja laitteen sormenjäljellä.
  • Kaikki lomakkeen kautta toimitettu tieto on puhdistettava XSS-hyökkäysten estämiseksi.

Nämä eivät ole erillisiä tietoturvatehtäviä; ne ovat olennainen osa ominaisuuden “valmis”-määritelmää.

Vaihe 4: Kytke vaatimukset tietoturvatestaukseen

Hyödyntämällä Zenith Controls -oppaan hallintakeinoa 8.29 Security testing varmistat, että jokaisella vaatimuksella on siihen liitetty testitapaus. Tämä sulkee silmukan ja tuottaa auditoitavissa olevaa näyttöä hallintakeinon tehokkuudesta.

• Vaatimus: Siirrettävien tietojen salaus TLS 1.3:lla. → Testi: Automaattinen skannaus TLS:n pakottamisen, varmenteen voimassaolon ja hyväksyttyjen salausalgoritmiryhmien varmentamiseksi.
• Vaatimus: Syötteen validointi SQL-injektion estämiseksi. → Testi: Automaattinen SAST/DAST-skannaus ja manuaalinen fuzz-testaus laadunvarmistusvaiheessa.
• Vaatimus: 15 minuutin käyttämättömyyteen perustuva istunnon aikakatkaisu. → Testi: Automaattiset ja manuaaliset testit, joilla vahvistetaan istunnon mitätöinti palvelinpuolella 15 minuutin käyttämättömyyden jälkeen.

Vaihe 5: Laajenna vaatimukset toimitusketjuun

Koska ISO-hallintakeino 8.26 liittyy Zenith Controls -oppaassa toimittajaturvallisuuteen (5.19, 5.20) ja ulkoistettuun kehittämiseen (8.30), prosessin on katettava myös kolmannen osapuolen koodi. Pk-yrityksille, jotka tukeutuvat vahvasti ulkoisiin kirjastoihin, Sovellusturvallisuusvaatimusten politiikka – pk-yritys -politiikan kohta on kriittinen:

Kaikki sovelluksessa käytettävät kolmannen osapuolen työkalut, lisäosat tai ulkoiset koodikirjastot on kirjattava ja katselmoitava vuosittain tietoturvavaikutuksen ja korjauspäivitysten tilan osalta.

Tämä yksinkertainen ja käytännönläheinen vaatimus pakottaa omaksumaan ohjelmiston materiaaliluettelon (SBOM) ajattelutavan, joka on keskeinen odotus esimerkiksi NIS2:n kaltaisissa säädöksissä. Merkittävien toimittajien osalta samat sovellusturvallisuusvaatimukset on sisällytettävä sopimuksiin viittaamalla ISO/IEC 27036-1 -standardiin (ICT-toimitusketjun tietoturva).

Vaihe 6: Ota käyttöön säännöllinen uudelleenarviointi

Kun sovellukset kehittyvät, myös niiden riskit muuttuvat. Zenith Blueprint -oppaan ohjeistus säännöllisestä uudelleenarvioinnista on keskeinen. Kun integroit uuden ohjelmointirajapinnan tai siirryt toiseen pilvipalveluun, riskikonteksti muuttuu. Tämän on käynnistettävä nykyisten tietoturvavaatimusten katselmointi sen varmistamiseksi, että ne ovat edelleen riittäviä. Tämä on linjassa ISO/IEC 27005:2024:n kanssa (jatkuva riskien käsittely) ja muuttaa sovellusturvallisuuden jatkuvaksi käytännöksi, ei kertaluonteiseksi projektiksi.

Hallintakeinojen ekosysteemin purkaminen osiin

ISO-hallintakeino ei koskaan ole olemassa tyhjiössä. Vaikuttava tietoturva perustuu toisiinsa kytkeytyvien toimenpiteiden verkostoon. Hallintakeinon 8.26 todellinen voima vapautuu, kun ymmärrät sen suhteen muihin hallintakeinoihin; tätä näkökulmaa Zenith Controls kuvaa yksityiskohtaisesti.

Hallintakeino 8.26 luokitellaan ennaltaehkäiseväksi hallintakeinoksi, mutta se toimii koko turvallisen kehitysprosessin keskussolmuna ja kytkeytyy seuraaviin:

• 8.25 - Secure development life cycle: Tämä on kattava viitekehys. Hallintakeino 8.26 tarjoaa täsmällisen mitä-sisällön (vaatimukset), joka on integroitava miten-prosessiin (SDLC-prosessi).
• 8.27 - Secure system architecture and engineering principles: Vaatimukset ohjaavat arkkitehtuuripäätöksiä ja varmistavat, että tietoturva on perustavanlaatuista.
• 8.28 - Secure coding: Kun vaatimukset on määritelty (esimerkiksi “estä SQL-injektio”), turvallisen ohjelmoinnin standardit antavat kehittäjille tekniikat vaatimuksen täyttämiseen.
• 8.29 - Security testing in development and acceptance: Tämä hallintakeino validoi, että kohdassa 8.26 määritellyt vaatimukset on toteutettu oikein.
• 5.34 - Privacy and protection of PII: Kun sovellus käsittelee henkilötietoja, kohdasta 8.26 johdettujen vaatimusten on sisällettävä sisäänrakennetun tietosuojan periaatteet.
• 5.19 & 5.20 - Information security in supplier relationships: Hankittujen tai ulkoistettujen sovellusten osalta hallintakeino 8.26 määrää, että tietoturvavaatimukset on ulotettava toimitusketjuun.

Kun näitä hallintakeinoja tarkastellaan ekosysteeminä eikä tarkistuslistana, voidaan rakentaa monikerroksinen ja puolustettavissa oleva tietoturvatila.

Auditoijan näkökulma: valmistautuminen tarkasteluun

Auditoijat ajattelevat näytön kautta. Valmistautuaksesi sinun on ymmärrettävä erilaiset näkökulmat, joista auditoija voi asiaa tarkastella. Zenith Controls -oppaan auditointimenetelmäosio ennakoi näitä erilaisia lähestymistapoja.

Näiden näkökulmien ymmärtäminen auttaa valmistelemaan kattavan näyttöportfolion, joka osoittaa organisaatioon sisäänrakennetun, elävän ja toimivan prosessin.

Vaatimustenmukaisuuden yhteiskartoituksen kompassi: yksi prosessi, monta viitekehystä

Marian kaltaiselle yritykselle DORA:n, GDPR:n ja NIS2:n täyttäminen on pakollista. Hallintakeinojen manuaalinen kartoittaminen johtaa helposti päällekkäiseen työhön ja vaatimustenmukaisuuden aukkoihin. Keskitetty vaatimustenmukaisuuden yhteiskartoituksen lähestymistapa tuottaa merkittävää arvoa. Sovellusturvallisuusvaatimusten määrittely on käytännön toteutus sisäänrakennetun tietoturvan periaatteesta, joka on kaikkien näiden nykyaikaisten säädösten perustana.

Toteuttamalla vahvan prosessin sovellusturvallisuusvaatimuksille ISO/IEC 27002:2022:n perusteella rakennat samalla näyttöä, joka täyttää merkittävän osan näiden muiden säädösten vaatimuksista. Et vain “tee ISO:a”; rakennat yleisesti vaatimustenmukaista tietoturvaohjelmaa.

Kaaoksesta hallintaan: etenemispolkusi

Marian tarinalla on myönteinen lopputulos. Hän käytti maksupportaalin tapausta muutoksen katalysaattorina. Selkeän Clarysecin politiikkaviitekehyksen ja käytännön toteutusohjeen avulla hän toi kehitys-, tietoturva- ja tuotetiimit yhteen. Tiimit käyttivät Zenith Blueprint -menetelmää portaalin vaatimusten takautuvaan määrittelyyn ja priorisoivat korjaavat toimenpiteet riskin perusteella.

Vielä tärkeämpää oli, että he loivat uuden työskentelytavan. “Tietoturvatarkistuslista” korvattiin yhteisillä suunnittelutilaisuuksilla. Kun DORA-auditoijat saapuivat, Maria pystyi näyttämään heille paitsi turvallisen sovelluksen myös kypsän ja toistettavan prosessin, jolla varmistetaan, että kaikki tulevat sovellukset rakennetaan tietoturvan perustalle.

Sovellusturvallisuuden tilan muuttaminen alkaa yhdestä jäsennellystä askeleesta. Etenemispolkusi on selkeä:

1. Perusta hallinto: Ota käyttöön muodollinen politiikka sovellusturvallisuusvaatimusten määrittelylle. Mallimme, kuten Sovellusturvallisuusvaatimusten politiikka, tarjoavat auditointivalmiin lähtökohdan.
2. Ota käyttöön käytännönläheinen viitekehys: Käytä Zenith Blueprint -opasta integroidaksesi tietoturvavaatimukset suoraan kehityksen elinkaareen siten, että niistä tulee toteuttamiskelpoisia, testattavia ja jäljitettäviä.
3. Ymmärrä koko konteksti: Hyödynnä Zenith Controls -opasta nähdäksesi, miten tämä kriittinen hallintakeino liittyy laajempaan tietoturvaekosysteemiin ja miten se kartoittuu DORA:n, NIS2:n, GDPR:n ja muiden vaatimusten välillä.
4. Skaalaa sovellusportfolioon: Kun lähestymistapa toimii yhden sovelluksen osalta, skaalaa se koko portfolioon integroimalla tietoturvavaatimusten malli vakiomuotoisiin projektin käynnistyksen tarkistuslistoihin, ketteriin malleihin ja hankintaprosesseihin.

Jos haluat nopeuttaa tätä muutosta, Clarysec tarjoaa valmiit politiikat, toteutuksen tiekartat ja vaatimustenmukaisuuden yhteiskartoitukset, joiden avulla siirryt hajanaisista toimista osoitettavasti kypsään ja auditointivalmiiseen ohjelmaan. Älä käsittele sovellusturvallisuutta enää loppuvaiheen tarkastusporttina. Ala rakentaa sitä kaiken luomasi suunnitelmaan.