1. 사후 고려 사항으로서의 보안

개발자 수는 대부분의 조직에서 보안 전문가 수보다 훨씬 많습니다. 개발자가 코드를 만들고 개발 주기의 후반 단계에서 보안을 포함하도록 하는 것은 릴리스의 빠른 속도와 양으로 인해 패배하는 싸움입니다. 이 접근 방식은 모든 애플리케이션을 포괄하도록 확장되지 않으며, 너무 늦어질 때까지 취약성이 발견되지 않도록 하므로 취약성 코드가 프로덕션으로 밀려납니다.

솔루션: 보안을 시프트 레프트하고 개발 초기 단계부터 모든 애플리케이션을 포괄하도록 보안 노력을 확장합니다.

2. 사일로 및 Dev-Sec 마찰

전통적으로 개발자와 보안 팀 간의 커뮤니케이션은 문제 중심 또는 사고 중심인 경향이 있습니다. 그러나 이메일, PDF 보고서 또는 GitHub 문제만으로 대량 커뮤니케이션을 하면 마찰이 발생하여 모두에게 불만을 안겨줍니다. 개발자의 경우, 보안으로 인해 제기된 문제는 일상적인 개발에 중요하지 않거나 이미 완료된 프로젝트에 대한 피드백이 포함될 수 있습니다. 이러한 문제를 해결하면 스프린트 작업과 노력을 재조정해야 하는 스트레스만 가중되어 보안이 혁신의 걸림돌이 됩니다. 보안 팀의 경우 아키텍처, 설계 및 개발 초기 단계에 참여하지 않는 것이 답답합니다. 수년간의 보안 전문 지식이 없는 개발자에게 조직 및 애플리케이션 보안 위험을 설명하는 것도 어려울 수 있습니다. 결국 커뮤니케이션이 제대로 이루어지지 않으면 전반적으로 협업과 공감이 줄어들게 됩니다.

솔루션: 개발자 워크플로에 도구를 통합하여 보안을 개발의 일부로 만듭니다. 두 팀 간의 토론과 비동기식 협업을 촉진합니다.

3. 확인란 연습으로서의 보안

보안의 중요성이 조직마다 다른 것처럼, 실제 보안 관행도 조직마다 다릅니다. 공식적인 보안 정책과 이 정책이 실제로 적용되는 방식의 차이는 혼란스럽고 보안 문제의 우선순위를 정하는 것이 더욱 복잡해질 수 있습니다.

또한 애플리케이션 보안은 조직 전체 사이버 보안 노력의 극히 일부에 불과하며 개발 및 CI/CD와 격리되는 경향이 있다는 점도 명심하세요. 이는 다음과 같은 나쁜 습관으로 이어집니다.

품질보다 양을 중요하게 생각합니다. 수많은 저품질 보안 검색 결과나 취약성에 집중한다고 해서 더 큰 문제가 해결되는 것은 아니며 개발자에게 더 많은 작업이 추가될 뿐입니다. 보안을 개발 문제로 만드는 것. 원시 보안 스캔을 이슈 트래커에 연결하면 개발자가 모두 수정할 것이라고 가정하는 것만으로도 개발자는 보안 관련 문제에 대한 민감도를 완화할 수 있습니다. 측정값이 아닙니다. 다른 이니셔티브와 마찬가지로 애플리케이션 보안 노력의 가치와 ROI는 지속적으로 측정 및 평가되어야 합니다. 그렇지 않으면 데이터 부족으로 인해 조직의 발목을 잡을 수 있으며 보안 개선이 이루어지고 있다는 증거를 보여주지 못할 수도 있습니다.

솔루션: 즉각적인 해결책을 찾으려면 제한된 수의 실제 보안 문제를 해결하는 데 집중한 다음, 수많은 잘못된 긍정을 공유하는 대신 우선순위를 정해 개발자에게 제시합니다. 더 큰 규모로 새로운 보안 문제를 '코드화'하고 프로덕션 브랜치에 통합되는 것을 방지할 수 있는 보안 도구를 찾아보세요. 보안 도구는 실제로 코드를 개선할 수 있으므로 시간이 지남에 따라 애플리케이션 보안 프로그램의 가치와 영향을 계속 측정해야 합니다.