Największym czynnikiem wpływającym na ewolucję bezpieczeństwo aplikacji to szybkość, z jaką zmienia się technologia. Wynika to w dużej mierze z powszechnej konsumeryzacji – ludzie oczekują, że nowe technologie i aktualizacje będą szybko dostępne, ponieważ oczekują bezproblemowej obsługi konsumentów.
Ten trend w połączeniu z szerszym wprowadzeniem Oprogramowanie jako usługa (SaaS) doprowadziło do szybkich, iteracyjnych cykli rozwoju, w których zmiany w oprogramowaniu są wprowadzane co tydzień, codziennie, a nawet co godzinę. Tradycyjne praktyki bezpieczeństwa aplikacji nie nadążają za tempem. To jest gdzie DevSecOps wchodzi.
DevSecOps to sposób myślenia i sposób pracy w obszarze bezpieczeństwa aplikacji, w którym bezpieczeństwo jest częścią pracy każdego, a nie tylko jednego zespołu. Pomaga skalować zabezpieczenia z takim samym tempem zmian, jak nowe cykle rozwoju, jednocześnie podnosząc znaczenie bezpieczeństwa do bardziej tradycyjnych wskaźników sukcesu biznesowego, takich jak dostępność produktu lub jakość.
Jednak firmy historycznie miały trudności z wdrożeniem DevSecOps w swoich organizacjach. Jedną z najbardziej uporczywych barier jest to, że może to być duża zmiana kulturowa dla zespołów technologicznych i często wiąże się ze zmianą oprzyrządowania. Ale jeśli zostanie to zrobione prawidłowo, DevSecOps może mieć znaczący wpływ na wzmocnienie bezpieczeństwa aplikacji. I choć może się to wydawać sprzeczne z intuicją, najlepszą strategią jest uczynienie DevSecOps odpowiedzialnością Inżynieria – nie bezpieczeństwo.
Co sprawia, że DevSecOps jest tak trudny do przyjęcia?
Niedawne incydenty związane z cyberbezpieczeństwem, takie jak Log4j oraz Słoneczne Wiatry pokazali zespołom wykonawczym, że nie mogą już sobie pozwolić na utrzymywanie bezpieczeństwa w silosie. Zamiast tego muszą uczynić to fundamentem strategii firmy, od sali konferencyjnej po centrum rozwoju oprogramowania.
Z dnia na dzień luka Log4j stała się problemem dla tysięcy firm korzystających w swoim oprogramowaniu z otwartego frameworka Log4j do logowania. Chociaż luka została załatana, zanim cyberprzestępcy mogli spowodować poważne szkody, ujawniła, jak wiele wciąż nie wiadomo na temat wielu programów wchodzących w skład szerokiej gamy systemów.
I chociaż atak SolarWinds dotknął łańcuchy dostaw, wskazuje na podobny problem z widocznością: zbyt wiele firm nie rozumie w pełni zakresu ich operacji oprogramowania lub tego, jak ich kod wpływa na ich ogólny profil zagrożenia, dając cyberprzestępcom możliwość narzędzia infrastruktury końcowej i inne niemonitorowane luki w zabezpieczeniach.
DevSecOps może być trudny do wdrożenia, ponieważ wiąże się ze zmianą sposobu myślenia zespołów ds. bezpieczeństwa, inżynierów i programistów. Skanowanie kodu — jedno powszechne podejście zaimplementowane w ramach DevSecOps — często może oznaczać fałszywe alarmy. To z kolei powoduje niepotrzebną pracę dla programistów i może prowadzić do tego, że nie będą chcieli przestrzegać odpowiednich procedur bezpieczeństwa w celu sprawdzenia swojego kodu.
Tymczasem zespoły ds. bezpieczeństwa często borykają się z widoczną utratą kontroli. Firmy muszą znaleźć lepszy mechanizm integracji automatyzacji z wiedzą specjalistyczną, aby osadzić zabezpieczenia w procesie rozwoju bez spowalniania operacji lub minimalizowania ogólnego stanu bezpieczeństwa firmy.
Jak firmy mogą wdrożyć DevSecOps?
Wdrażanie DevSecOps zaczyna się od zrozumienia kultury firmy i sposobu działania programistów. Ze względu na obecną strukturę zachęt wiele zespołów inżynierskich koncentruje się na ułatwieniu dostępności i jakości produktów, ale bezpieczeństwo ma również bezpośredni wpływ na te wskaźniki biznesowe. Kiedy firmy ograniczają bezpieczeństwo do zespołu ds. bezpieczeństwa i delegują wszystkie inne prace programistyczne do inżynierii, tracą szansę na ułatwienie naprawdę wydajnej współpracy.
Jeśli organizacje chcą, aby ich programiści włączyli zabezpieczenia do swojej codziennej pracy, muszą najpierw zrozumieć procesy programistów, problemy i motywacje. Odpowiedzi na te pytania mogą pomóc zespołom lepiej zintegrować zabezpieczenia z procesem DevOps, aby pracować dla ich programistów, a nie przeciwko nim.
Wskazuje również, dlaczego DevSecOps musi stać się obowiązkiem zespołu inżynierów. Zapewnienie, że inżynieria ma głos w procesie DevSecOps, daje im poczucie własności nad bezpieczeństwem i pozwala im wybrać narzędzia, które będą działać najlepiej w ich konkretnym środowisku.
Umieszczenie odpowiedzialności w inżynierii jest kluczową zmianą w kierunku przyjęcia sposobu myślenia DevSecOps.
Co dalej?
Tempo, z jakim rozwija się technologia, będzie nadal przyspieszać. W rezultacie organizacje muszą priorytetowo traktować wgląd w bezpieczeństwo aplikacji, aby nadążyć za tymi zmianami.
Już teraz rośnie ilość informacji o tym, w jaki sposób firmy mogą poprawić swoją widoczność, aby zrozumieć, gdzie rozmieścić zasoby, aby wzmocnić swoją pozycję w zakresie bezpieczeństwa – a ilość ta będzie się zwiększać z czasem. Jest zestawienie komponentów oprogramowania (SBOM) odpowiedź? Jeśli tak, jaki jest najlepszy sposób utworzenia i opublikowania tego SBOM?
Ostatecznie bezpieczeństwo aplikacji polega na robieniu tego, co jest właściwe dla klientów. Jeśli firmy tworzą i wypuszczają niezabezpieczone produkty, szkodzi to ich reputacji biznesowej oraz klienci. DevSecOps wbudowuje bezpieczeństwo w sedno sukcesu biznesowego, dzięki czemu firmy mogą działać właściwie zarówno dla swoich użytkowników końcowych, jak i dla siebie. Aby zwiększyć adopcję DevSecOps w całej organizacji, firmy powinny nałożyć ciężar bezpieczeństwa na zespoły, które budują swoje rozwiązania.
Mandy Andress jest dyrektorem ds. bezpieczeństwa informacji w Elastycznyfirma zajmująca się wyszukiwaniem korporacyjnym i ma ponad 25-letnie doświadczenie w zarządzaniu ryzykiem i bezpieczeństwem informacji.