How does your business approach application development? If you’re like many companies, DevOps is your watchword, and with good reason. Historically, a strong DevOps program allowed for agile operations, shortened the development lifecycle, and gave customers consistent access to the immediate solutions they demand. DevOps has been a powerful solution for tech companies of all sizes – but the problem is that it’s not enough.
Over the last several years, industry experts have encouraged businesses to shift left, taking a DevSecOps approach to application development. Security, these experts argue, needs to be part of the initial development process if applications are actually going to be secure. Why, then, are so many companies hesitant to deploy a DevSecOps approach? It’s a complicated problem, but one that, with proper examination, can be solved to everyone’s advantage.
When the concept of DevSecOps was first introduced, one of the first arguments that companies offered against it was that, instead of encouraging agility, foregrounding security would slow application development down. This can happen, but only if companies don’t sufficiently automate the security code review process. As long as that happens, though, DevSecOps doesn’t actually make application development and deployment slower. It can even be faster than the older DevOps model.
DevSecOps는 애플리케이션 개발 프로세스를 어떻게 가속화하나요? 애플리케이션을 구축한 후 마지막까지 보안 요소를 통합하려면 이러한 중요한 구성 요소를 기존 인프라에 맞출 수 있는 방법을 찾아야 합니다. 탑을 쌓은 다음 탑이 완성된 후 중앙에 대들보를 삽입하는 것과 같습니다. 가능할 수도 있지만 이미 수행한 모든 작업을 중단해야 합니다. 반면에 왼쪽으로 이동하여 보안을 구축하는 방식을 선택하면 더 강력한 시스템과 깔끔한 구성 요소를 갖추게 됩니다.
It may sound ridiculous, but if you talk to some DevOps-focused businesses, you’ll occasionally hear people say that a DevSecOps approach leads to more security breaches, not fewer. Like other assertions about DevSecOps, though, this one is also rooted in serious misunderstandings of the practice. While top DevSecOps users report more breaches than their DevOps counterparts, experts agree that this is only because they’re aware of those breaches, not because they actually experience more of them. DevOps-based companies simply can’t detect security breaches.
Obviously, it’s better for businesses to be aware of potential or actual security risks because that enables them to actually address and remedy their weaknesses, but many businesses are hesitant to admit that they’re at risk. It’s important for companies to acknowledge that DevSecOps enables risk detection, and that acknowledging breaches is less likely to damage a company than being oblivious to digital attacks.
비즈니스 관행을 변경하는 데는 많은 비용이 들 수 있습니다. 이전 프로그램 세트에서 전환하든 코딩 언어를 변경하든, 중대한 변경으로 인해 비즈니스가 중단되고 계약과 수익을 잃을 수 있습니다. DevSecOps 로 이동하는 경우에도 마찬가지인가요? 단기적으로는 팀원들이 새로운 시스템을 학습하도록 지원하면 업무가 지체될 수 있지만, 장기적으로는 DevSecOps를 통해 ROI를 극대화할 수 있습니다.
DevSecOps 접근 방식은 어떻게 회사의 수익성을 높일 수 있을까요? 물론 주요 보안 문제가 발생하기 전에 미리 예방하고 공격을 받았을 때 신속하게 대응할 수 있는 것이 재정적으로 유리한 것은 사실이지만, 이것이 유일한 이유는 아닙니다. DevSecOps가 실제로 더 민첩한 시스템, 즉 DevOps 접근 방식에서 가능한 것보다 더 빠르게 시작하고 업데이트하는 시스템을 만든다는 위의 주장을 상기해 보세요. 또한 전문가의 지원을 통해 기업은 보안 인프라를 자동화하여 시간이 많이 걸리고 고도의 기술이 필요한 프로세스를 간소화할 수 있습니다.
DevOps highlights two main elements of the application creation process – the development side and the operations, or customer-facing, side – but despite the shorthand conjunction of the two, it doesn’t really connect them. A DevOps approach still allows professionals to work within their familiar siloes. Developers build apps that enable smoother operations, and operations teams may provide guidance and feedback, but they don’t really have to work together. That all changes when companies shift-left to DevSecOps, and that’s a key reason why businesses have been reticent to make the change.
일반적으로 애플리케이션 개발자와 보안 전문가는 코딩 과정 후반에 애플리케이션에 보안 기능을 추가하기 때문에 프로젝트를 따로 진행했습니다. 하지만 기본적인 개발과 보안 기능을 동시에 구축할 때는 이전에는 사일로화되어 있던 팀들이 한데 모여야 합니다. 이를 성공적으로 수행하려면 리더십은 팀 간의 커뮤니케이션을 촉진하고 교차 교육을 장려해야 합니다. 보안 전문가는 전문 코더는 아닐지라도 개발자에게 지침을 제공할 수 있습니다. 반대로 개발자는 보안이 기능적 우선 순위임을 인식해야 합니다.
정보를 사일로에 격리하는 현재의 경향이 많은 클라우드 보안 침해의 원인이므로 개발자와 보안 전문가 간의 커뮤니케이션을 늘리는 것이 특히 중요합니다. 실제로 최근 연구에 따르면 애플리케이션의 사용자 측인 퍼블릭 클라우드에서 발생하는 침해의 60%가 부적절한 배포로 인해 발생한다고 합니다. 개발자가 클라우드 배포와 관련하여 올바른 구성 결정을 내리지 못하면, 적어도 지원 없이는 비즈니스가 공격에 노출될 수 있습니다. DevSecOps 관점으로 전환하면 이러한 격차를 해소할 수 있지만, 이미 모범 사례를 사용하고 있다고 생각하는 개발자의 방어력도 높일 수 있습니다.
These four arguments are just some of the reasons that businesses have been slow to shift-left and adopt a DevSecOps approach, but they’re hardly the only ones. Like so many other changes, companies are resistant to change, even when it’s in their best interest. The problem is that sometimes you have to let go of the old ways in order to be successful.
If your business is stuck in the old DevOps mentality, it’s time to move forward – and Check Point can help. Contact us today for a free security assessment and to learn more about how DevSecOps can benefit your company. Making a big change isn’t easy, but with the right support, you’ll see big improvements.
피드백