Kuinka DevSecOps antaa kansalaisten kehittäjille mahdollisuuksia

Vuoteen 2025 mennessä yhteensä globaalin tiedon luominen saavuttaa 181 zettatavua. Yrityksille nämä tiedot ovat voimavara, jonka avulla ne voivat hyödyntää erilaisia ​​​​teknologia-alustoja luodakseen erittäin yksilöllisiä asiakaskokemuksia, jotka synnyttävät uskollisuutta ja houkuttelevat uutta liiketoimintaa. Nämä kokemukset ovat kuitenkin riippuvaisia ​​pilviinfrastruktuureista, jotka käyttävät jaettuja suojaustiloja. Siinä piilee riski, ja se kasvaa, kun teknologia kasvaa ja sisältää uuden armeijan kansalaiskehittäjiä, jotka käyttävät matalan koodin ja ilman koodia alustoja.

Perinnön ajattelutavan ymmärtäminen ja voittaminen 

Gartner arvioi, että vuoteen 2025 mennessä 70 prosenttia yrityssovelluksista rakennetaan matalan koodin ja ilman koodia sisältäville alustoille, kuten Salesforce ja ServiceNow. Perintöpohjaisella ajattelutavalla vastaaminen on varma tapa asettaa yli kaksi kolmasosaa yrityssovelluksista epäonnistumaan.   

"Perinnöllinen ajattelutapa" on osuva kuvaaja infrastruktuuria vaivaaville ongelmille. Se tuo mieleen rikkaat, hemmotellut lapset, jotka ovat täysin riippuvaisia ​​tehdystä työstä ja ennen heitä tulleista ihmisistä. Se ei ole hyvä tapa rakentaa perintöä, ja se on yhtä huono tapa rakentaa järjestelmä.

Kun sinulla on perinteinen ajattelutapa, oletat, että infrastruktuuri on asetettu. Alusta on turvallinen ja turvallisuus on sisäänrakennettu. Luottamus oletetaan yksinkertaisesti siksi, että tekniikka oli olemassa ennen järjestelmänvalvojaa.

Tämä perinnöllinen ajattelutapa vaivaa matalakoodia ja ei-koodia käyttäviä alustoja. Käyttäjät luottavat alustan turvallisuuteen kuljettaessaan heidät koko yrityksen infrastruktuurin läpi. Sen sijaan kyseisen alustan turvallisuuden tulisi koskea vain tätä alustaa.

Oletetaan, että Salesforce-kehittäjät luovat automaattisen määritysohjelman uusille liideille. He käyttävät sitä Salesforcessa sisäisiin tehtäviin, ja se on hyvä. He voivat luottaa alustan turvallisuuteen. He päättävät laajentaa sitä automaation parantamiseksi. He yhdistävät ohjelman ulkopuoliseen CRM:ään, kuten ServiceNow, SAP tai Oracle. Perinnöllinen ajattelutapa ottaa vallan: Salesforce on turvallinen. ServiceNow, SAP tai kolmas osapuoli on turvassa.

Joten Salesforce + kolmas osapuoli = turvallinen.

Mutta tuossa plusmerkissä on paljon tuntematonta. Miten Salesforcessa luotu sisäinen ohjelma yhdistetään turvallisesti ja yhteensopivasti kolmannen osapuolen alustalla luotuun ulkoiseen ohjelmaan? Siinä yksittäisessä hahmossa on paljon tilaa virheille.  

Ja se on vain yksi yhteys. Monet Salesforcessa luodut ohjelmat koskettavat satoja muita. Se tarkoittaa, että satoja tuntemattomia kohdellaan yllä kuvatulla plusmerkillä ihmisiltä, ​​joilla on vähän tai ei ollenkaan kehityskokemusta.  

Ainoa ratkaisu on viedä tämä kehitys takaisin maan pinnalle ja palata DevSecOps-periaatteisiin.

DevSecOps-kehyksen perustaminen 

DevSecOps puitteita on kirjoitettu, kirjoitettu uudelleen ja kirjoitettu uudelleen konseptin luomisen jälkeen. Pyörää ei tarvitse keksiä uudelleen niiden perustamisen yhteydessä, etenkään silloin SAFECOde ja Cloud Security Alliance on rakentanut kuusi pilaria:

1. Kollektiivinen vastuu: Turvallisuus on jokaisen yrityksen työntekijän vastuulla – mutta ihmiset eivät voi täyttää standardeja, joita he eivät tunne. Leidit tulisi määrittää kyberturvallisuuspolitiikan ohjaamiseksi ja sen levittämiseksi koko yritykseen.  
2. Yhteistyö ja integraatio: Tietoa on jaettava ja siirrettävä. Puolet syy siihen, miksi yritykset joutuvat vanhaan ajattelutapaan, on se, että kaikki vanhan järjestelmän tunteneet ovat poissa. Jatkuva tiedon jakaminen auttaa poistamaan tämän ongelman.
3. Pragmaattinen toteutus: Pragmaattinen toteutus liittyy kehittäjäkokemukseen. Vaikeita, arkipäiväisiä ja raskaita prosesseja ei seurata pitkään. Tietoturva tulisi sisällyttää kehityskäytäntöihin – eli jokainen koodirivi vaatii testirivin. Tehokas yritys vie sitä pidemmälle käyttämällä työkalua, joka automatisoi jokaisen testikoodirivin.
4. Vaatimustenmukaisuus ja kehitys: Vaatimusten noudattamisen tulee ohjata kehitysprosessia siten, että kehittäjät eivät voi poiketa niistä. Esimerkiksi rahoituslaitoksen kehittäjä työskentelee alustalla, joka on suunniteltu noudattamaan Gramm-Leach-Bliley-lakia. Kehittäjän ei tarvitse tietää toiminnan yksittäisiä yksityiskohtia ollakseen yhteensopiva, koska ne on sisäänrakennettu alustaan.  
5. Automaatio: Tehtävät, jotka ovat ennustettavissa, toistettavissa ja suuria, tulee automatisoida aina kun mahdollista, jotta kehittäjien taakka voidaan poistaa ja inhimillisten virheiden riskiä pienentää.
6. Monitor: Nykyaikaiset pilviinfrastruktuurit muuttuvat ja kasvavat. On elintärkeää seurata sitä – ihannetapauksessa jonkinlaisen orkestroinnin avulla, joka mahdollistaa yhdellä silmäyksellä näkevän kaikki erilaiset keskinäiset yhteydet.

Jonkin sisällä alhainen tai ei-koodi ympäristön kannalta nämä pilarit eivät ole niin yksinkertaisia ​​kuin voisi odottaa. Näitä työkaluja käyttävät ihmiset ovat usein yritysasiantuntijoita, jotka eivät tunne DevSecOpsin perusteita.

Ihmisten, prosessien ja teknologian yhdistäminen

Matalakoodin ja ilman koodia sisältävien alustojen käyttö voi itse asiassa auttaa kuromaan umpeen tämän taitojen puutteen. Työntekijät haluavat oppia uusia taitoja. Yritykset voivat tukea sitä perustamalla DevSecOps-kehyksen, joka keskittyy ihmisiin, prosesseihin ja teknologiaan. 

• Prosessit: Nollaluottamusympäristössä matalan koodin ja ilman koodia kehittäjien ei tarvitse huolehtia yhteyksien muodostamisesta, jotka vaarantavat järjestelmän eheyden, koska he eivät pysty siihen. Heillä ei ole perustason auktoriteettia eristetyn järjestelmänsä ulkopuolella.  
• ihmiset: Vastuun kulttuuri on eri asia kuin syyttelykulttuuri. Vastuu tarkoittaa, että yksilöt tuntevat olonsa mukavaksi esitelläkseen ongelman tai virheen, koska painopiste on ongelmassa, ei henkilössä.
• Teknologia: Teknologia on suurin yksittäinen este DevSecOps-periaatteiden asianmukaiselle toteuttamiselle, koska se ei ole kehittäjien käsissä. Heidän on käytettävä sitä, mitä organisaatio antaa heille. Jos tämä tekniikka ei toimi, kehittäjät keksivät ratkaisuja, jotka eivät ole turvallisia. Pohjimmiltaan teknologiasta tulee yksi suuri varjo-IT-generaattori.

Elämme jännittäviä kehitysaikoja. Yhä useammalla ihmisellä on mahdollisuus rakentaa ohjelmistoja, testata strategioita ja parantaa liiketoiminnan arvoa. Mutta siihen liittyy riski. Yritykset, jotka etsivät tapoja siirtää tämä riski teknologiaan, pitävät kehityksensä maanläheisenä jättäen samalla tilaa tutkimiselle.