År 2025 totalt globalt dataskapande kommer att nå 181 zettabyte. För företag är denna data en tillgång, vilket gör att de kan utnyttja en mängd olika teknikplattformar för att skapa mycket personliga kundupplevelser som skapar lojalitet och attraherar nya affärer. Dessa upplevelser är dock beroende av molninfrastruktur som använder delade säkerhetslägen. Det är där risken ligger, och den ökar i takt med att tekniken växer för att införliva en ny armé av medborgarutvecklare som använder plattformar med låg kod och ingen kod.
Förstå och övervinna arvstänket
Gartner uppskattar att år 2025 kommer 70 % av företagsapplikationerna att byggas från plattformar med låg kod och ingen kod som Salesforce och ServiceNow. Att svara med ett arvsbaserat tankesätt är ett säkert sätt att ställa in mer än två tredjedelar av företagsappar för att misslyckas.
"Arvstänk" är en lämplig beskrivning av problemen som plågar infrastrukturen. Det för tankarna till ett rikt, bortskämt barn som är helt beroende av det arbete som utförs och människor som kom före dem. Det är inte ett bra sätt att bygga ett arv, och det är ett lika dåligt sätt att bygga ett system.
När du har ett äldre tänkesätt antar du att infrastrukturen är inställd. Plattformen är säker och säkerheten är inbyggd. Förtroende antas helt enkelt för att tekniken fanns där innan administratören.
Det arvstänket plågar plattformar med låg kod och ingen kod. Användare litar på säkerheten hos en plattform för att bära dem genom en hel företagsinfrastruktur. Istället bör säkerheten för den plattformen endast gälla för den plattformen.
Låt oss säga att Salesforce-utvecklare skapar ett automatiskt tilldelningsprogram för nya potentiella kunder. De använder det inom Salesforce för interna uppdrag, och det är bra. De kan lita på plattformens säkerhet. De bestämmer sig för att utöka den för att förbättra automatiseringen. De ansluter det programmet till en extern CRM som ServiceNow, SAP eller Oracle. Arvstänket tar över: Salesforce är säkert. ServiceNow, SAP eller tredje part är säkert.
Så, Salesforce + tredje part = säker.
Men det finns en hel del okänt i det plustecknet. Hur kopplar du på ett säkert och följsamt sätt det interna programmet som skapats i Salesforce till det externa programmet som skapats i tredjepartsplattformen? Det finns mycket utrymme för misstag i den enda karaktären.
Och det är bara ett samband. Många program skapade i Salesforce berör hundratals andra. Det är hundratals okända som behandlas som plustecknet som beskrivs ovan av människor som har liten eller ingen erfarenhet av utveckling.
Den enda lösningen är att ta den utvecklingen tillbaka till jorden med en återgång till DevSecOps principer.
Etablering av DevSecOps-ramverket
DevSecOps ramar har skrivits, skrivits om och skrivits igen sedan konceptet skapades. Det finns ingen anledning att uppfinna hjulet på nytt när du etablerar dem, särskilt när SAFECode och Cloud Security Alliance har byggt sex pelare:
- Kollektivt ansvar: Säkerhet är varje persons ansvar i företaget – men människor kan inte uppfylla standarder de inte känner till. Leads bör tilldelas för att driva cybersäkerhetspolicy och säkerställa att den sprids över hela företaget.
- Samarbete och integration: Kunskap ska delas och överföras. Hälften av anledningen till att företag faller in i det gamla tänkesättet är att alla som kände till det gamla systemet är borta. Kontinuerlig kunskapsdelning hjälper till att eliminera detta problem.
- Pragmatisk implementering: Pragmatisk implementering knyter an till utvecklarupplevelsen. Processer som är svåra, vardagliga och svårhanterliga följs inte länge. Säkerhet bör byggas in i utvecklingsrutiner - det vill säga varje rad kod kräver en testrad. Ett högpresterande företag skulle ta det längre genom att använda ett verktyg för att automatisera varje rad med testkod.
- Efterlevnad och utveckling: Efterlevnadskrav bör styra utvecklingsprocessen på ett sätt som inte tillåter utvecklare att avvika från dem. En utvecklare för en finansiell institution, till exempel, skulle arbeta på en plattform som är designad för att vara kompatibel med Gramm-Leach-Bliley Act. Utvecklaren behöver inte känna till de individuella detaljerna i handlingen för att vara kompatibla eftersom de är inbyggda i plattformen.
- Automation: Uppgifter som är förutsägbara, repeterbara och höga volymer bör automatiseras när det är möjligt för att ta bort bördan från utvecklarna och minska risken för mänskliga fel.
- Övervaka: Moderna molninfrastrukturer förändras och växer. Det är viktigt att hålla reda på det - helst genom någon form av orkestrering som ger en överblick över alla olika sammankopplingar.
I en låg eller ingen kod miljön är dessa pelare inte så enkla som man kan förvänta sig. De som använder dessa verktyg är ofta affärsexperter med liten förtrogenhet med DevSecOps grunderna.
Att föra samman människor, processer och teknik
Användningen av plattformar med låg kod och ingen kod kan faktiskt hjälpa till att minska denna kompetensklyfta. Medarbetarna vill lära sig nya färdigheter. Företag kan stödja detta genom att etablera ett DevSecOps-ramverk med fokus på människor, processer och teknik.
- processer: I en miljö med noll förtroende behöver utvecklare med låg kod och ingen kod inte oroa sig för att göra anslutningar som äventyrar systemets integritet eftersom de är oförmögna att göra det. De har ingen baslinjeauktoritet utanför sitt isolerade system.
- människor: En kultur av ansvar skiljer sig från en kultur av skuld. Ansvarsskyldighet innebär att individer känner sig bekväma med att komma fram med ett problem eller misstag eftersom fokus ligger på frågan, inte personen.
- Teknik: Tekniken är det enskilt största hindret för korrekt implementering av DevSecOps-principerna eftersom det ligger utanför utvecklarnas händer. De måste använda det som organisationen ger dem. Om den tekniken inte fungerar kommer utvecklare att komma med lösningar som varken är säkra eller säkra. Tekniken blir i huvudsak en stor skugg-IT-generator.
Vi lever i en spännande tid för utveckling. Fler och fler människor har möjlighet att bygga mjukvara, testa strategier och förbättra affärsvärdet. Men med det följer risken. Företag som tittar på sätt att överföra den risken till teknik kommer att hålla sin utveckling nere på jorden samtidigt som de lämnar utrymme att utforska.
