Hvordan DevSecOps styrker Citizen Developers

Innen 2025, totalt global dataskaping vil nå 181 zettabyte. For bedrifter er disse dataene en ressurs, som lar dem utnytte en rekke teknologiplattformer for å skape svært personlige kundeopplevelser som skaper lojalitet og tiltrekker seg ny virksomhet. Disse opplevelsene er imidlertid avhengige av skyinfrastrukturer som bruker delte sikkerhetsmoduser. Det er der risikoen ligger, og den øker etter hvert som teknologien vokser for å innlemme en ny hær av borgerutviklere som bruker plattformer med lav kode og ingen kode.

Forstå og overvinne arvstankegangen 

Gartner anslår at innen 2025 vil 70 % av bedriftsapplikasjonene bygges fra plattformer med lav kode og ingen kode som Salesforce og ServiceNow. Å svare med en arvebasert tankegang er en sikker måte å sette mer enn to tredjedeler av bedriftsappene på for å mislykkes.   

"Arvetankegang" er en passende beskrivelse for problemene som plager infrastruktur. Det bringer tankene til et rikt, bortskjemt barn som er helt avhengig av arbeidet som er gjort og mennesker som kom før dem. Det er ikke en god måte å bygge en arv på, og det er en like dårlig måte å bygge et system på.

Når du har en eldre tankegang, antar du at infrastrukturen er satt. Plattformen er trygg, og sikkerheten er innebygd. Tillit antas rett og slett fordi teknologien var der før administratoren.

Denne arvstankegangen plager plattformer med lav kode og ingen kode. Brukere er avhengige av sikkerheten til en plattform for å bære dem gjennom en hel bedriftsinfrastruktur. I stedet bør sikkerheten til den plattformen bare gjelde for den plattformen.

La oss si at Salesforce-utviklere lager et automatisert tildelingsprogram for nye potensielle kunder. De bruker det i Salesforce for interne oppdrag, og det er greit. De kan stole på plattformens sikkerhet. De bestemmer seg for å utvide den for å forbedre automatiseringen. De kobler det programmet til en eksternt vendt CRM som ServiceNow, SAP eller Oracle. Arvetankegangen tar overhånd: Salesforce er trygg. ServiceNow, SAP eller tredjeparten er trygg.

Så, Salesforce + tredjepart = trygt.

Men det er mye ukjent i det plusstegnet. Hvordan kobler du det interne programmet opprettet i Salesforce på en sikker og kompatibel måte til det eksterne programmet opprettet i tredjepartsplattformen? Det er mye rom for feil i den enkelt karakteren.  

Og det er bare én sammenheng. Mange programmer opprettet i Salesforce berører hundrevis av andre. Det er hundrevis av ukjente som blir behandlet som plusstegnet beskrevet ovenfor av folk som har liten eller ingen utviklingserfaring.  

Den eneste løsningen er å ta den utviklingen tilbake til jorden med en tilbakevending til DevSecOps-prinsippene.

Etablering av DevSecOps-rammeverket 

DevSecOps rammeverk har blitt skrevet, omskrevet og skrevet igjen siden konseptet ble opprettet. Det er ikke nødvendig å finne opp hjulet på nytt når du etablerer dem, spesielt når SAFECode og Cloud Security Alliance har bygget seks søyler:

1. Kollektivt ansvar: Sikkerhet er ansvaret til hver person i bedriften – men folk kan ikke oppfylle standarder de ikke kjenner. Leads bør tildeles for å drive nettsikkerhetspolitikk og sikre at den spres over hele bedriften.  
2. Samarbeid og integrering: Kunnskap skal deles og overføres. Halvparten av grunnen til at bedrifter faller inn i den gamle tankegangen er at alle som kjente det gamle systemet er borte. Kontinuerlig kunnskapsdeling bidrar til å eliminere dette problemet.
3. Pragmatisk implementering: Pragmatisk implementering knytter seg til utvikleropplevelsen. Prosesser som er vanskelige, dagligdagse og uhåndterlige blir ikke fulgt lenge. Sikkerhet bør bygges inn i utviklingspraksis - det vil si at hver linje med kode krever en testlinje. En bedrift med høy ytelse vil ta det videre ved å bruke et verktøy for å automatisere hver linje med testkode.
4. Samsvar og utvikling: Samsvarskrav bør lede utviklingsprosessen på en måte som ikke tillater utviklere å avvike fra dem. En utvikler for en finansinstitusjon, for eksempel, vil jobbe på en plattform som er designet for å være i samsvar med Gramm-Leach-Bliley Act. Utvikleren trenger ikke å kjenne de individuelle inn- og utkantene av handlingen for å være kompatible fordi de er innebygd i plattformen.  
5. Automatisering: Oppgaver som er forutsigbare, repeterbare og høyt volum bør automatiseres når det er mulig for å fjerne byrden fra utviklere og redusere risikoen for menneskelige feil.
6. Monitor: Moderne skyinfrastruktur endres og vokser. Det er viktig å holde styr på det - ideelt sett gjennom en eller annen form for orkestrering som gir et raskt overblikk over alle de forskjellige sammenkoblingene.

I en lav- eller ingen kode miljø, er disse pilarene ikke så enkle som man forventer. Personene som bruker disse verktøyene er ofte forretningseksperter med lite kjennskap til DevSecOps grunnleggende.

Å bringe sammen mennesker, prosesser og teknologi

Bruken av plattformer med lav kode og ingen kode kan faktisk bidra til å lukke dette kompetansegapet. Ansatte ønsker å lære nye ferdigheter. Bedrifter kan støtte dette ved å etablere et DevSecOps-rammeverk med fokus på mennesker, prosesser og teknologi. 

• prosesser: I et miljø med null tillit trenger ikke utviklere med lav kode og ingen kode å bekymre seg for å opprette tilkoblinger som setter systemintegriteten i fare fordi de ikke er i stand til å gjøre det. De har ingen grunnlinjeautoritet utenfor deres isolerte system.  
• personer: En ansvarlighetskultur er forskjellig fra en skyldkultur. Ansvarliggjøring betyr at enkeltpersoner føler seg komfortable med å komme frem med et problem eller feil fordi fokus er på saken, ikke personen.
• Teknologi: Teknologi er den største enkeltbarrieren for riktig implementering av DevSecOps-prinsippene fordi den er utenfor utviklerens hender. De må bruke det organisasjonen gir dem. Hvis den teknologien ikke fungerer, vil utviklere komme med løsninger som verken er sikre eller trygge. I hovedsak blir teknologien en stor skygge-IT-generator.

Vi lever i en spennende tid for utvikling. Flere og flere mennesker har muligheten til å bygge programvare, teste strategier og forbedre forretningsverdien. Men med det følger risiko. Bedrifter som ser på måter å overføre denne risikoen til teknologien, vil holde utviklingen nede på jorden mens de gir rom for å utforske.