개발자는 “보안 코딩”을 어떻게 정의합니까?

이 기사의 한 버전이 에 게재되었습니다. 테크 리퍼블릭.여기에서 업데이트 및 신디케이트되었습니다.

‍

보안 팀과 개발자 팀의 목표가 일치하는 환경을 조성하는 것은 힘든 일이지만 필수적인 전투였습니다.아직 갈 길이 멀지만 소프트웨어 보안에 대한 공동 책임의 문을 여는 데 필요한 시너지 효과를 가로막는 장애물이 분명해지고 있습니다.현명한 기업은 전략을 발전시켜 이러한 위험을 피하고 생산적인 발전을 꾀하며 DevSecOps를 활용하여 인력 중심의 잠재력을 최대한 활용하고자 합니다.

제가 예상하지 못했던 것은 보안 코딩 행위를 구성하는 요소에 대한 인식이 논쟁의 여지가 있다는 것입니다.에반스 데이터 (Evans Data) 와 공동으로 진행한 새로운 연구에 따르면 이러한 감정은 흑백으로 드러났습니다.더 2022년 개발자 중심 보안 현황 설문조사 1200명의 현역 개발자의 주요 인사이트와 경험을 분석하여 보안 영역에서의 태도와 과제를 조명합니다.

주요 연구 결과 중 하나는 코딩할 때 보안을 최우선으로 생각하는 개발자는 14% 에 불과합니다..이는 개선의 여지가 크다는 것을 보여주지만, 우리가 이미 알고 있던 사실을 확인시켜줍니다. 개발자 세계에서는 기능 구축이 가장 중요하고 개발자들은 보안을 DNA의 일부로 삼을 준비가 되어 있지 않다는 것입니다.하지만 보안 코딩이 개발자에게 어떤 의미인지에 대한 개발자 정의 데이터와 결합하면 우려의 여지가 있습니다.

이러한 인식은 개발자의 근무 경험에 의해 좌우되며, 이는 개발자가 일반적인 취약점과의 싸움에서 중심이 되지 않는다는 많은 조직의 환경과 잘 어울립니다.이들의 역량 강화는 매우 중요하지만, 그동안은 “보안 코딩”의 범위와 보안 숙련된 개발자에게 기대할 수 있는 사항에 대해 신속하게 동일한 이해를 해야 합니다.

개발자 세계의 보안에 대해 이해하기 쉽게 설명해야 합니다.

사이버 보안은 기껏해야 다면적이고 다루기 힘든 존재입니다. 보안 코딩은 전체 환경의 일부에 불과하지만 시스템의 복잡한 톱니바퀴이기 때문에 전문가의 주의가 필요합니다.

설문 조사에 따르면 보안 코드를 사용하는 개념은 일반 개발자에게는 상당히 고립되어 있으며, 기본과 그 너머에 대한 전체적인 관점과는 대조적으로 범위가 단일 범주로 제한되는 경우가 많았습니다.개발자들은 취약점이 없는 새 코드를 작성하는 방식보다는 기존 (또는 사전 승인된) 코드를 사용하는 데 의존한다고 밝혔습니다.타사 구성 요소 (특히 패치 적용) 에 대한 보안 인식과 Log4Shell 사태는 다음과 같은 좋은 예입니다. 12월 이후 30% 의 인스턴스가 패치가 적용되지 않은 상태로 유지) 는 기존 코드를 테스트하는 것과 마찬가지로 매우 중요하며, 이것만으로는 기능 수준의 보안 코딩 능력을 충족하지 못합니다.

코드 수준의 취약점은 잘못된 코딩 패턴을 학습한 개발자에 의해 도입되며, KPI에 보안 코드를 작성하는 데 중점을 두지 않는 것 (취약한 보안 문화와 맞물림) 은 이를 수용 가능한 표준으로 뒷받침할 뿐입니다.

보안 리더는 개발 집단에 보안 코딩이 수반하는 전체 상황을 먼저 보여줌으로써 초기 인식을 개선하고 가장 시급한 지식 격차 영역을 식별하는 데 많은 노력을 기울일 수 있습니다.사전 승인된 코드를 테스트하고 스캔하는 것도 하나의 기능이지만 취약성을 줄이려면 활발하게 사용되는 언어와 프레임워크를 사용한 우수하고 안전한 코딩 패턴에 대한 실습 교육이 필요합니다.

컨텍스트는 개발자 기술 향상에 매우 중요하며 비즈니스의 보안 목표와 관련하여 개발자를 여정에 참여시켜야 합니다.

많은 조직에서 보안 프로그램을 업그레이드해야 합니다.

소프트웨어 기반 기술이 폭발적으로 증가하면서 지난 10년간 사이버 보안 사고가 급속히 증가함에 따라, 우리 모두는 중요한 시스템의 악용을 발견하기 위해 24시간 내내 노력하는 위협 행위자를 따라잡기 위해 분주히 움직이고 있습니다.

DevSecOps 방법론은 개발자를 포함한 모든 사람이 보안에 대한 책임을 공유한다는 아이디어를 기반으로 하며 SDLC 초기부터 주요 고려 사항이었습니다.문제는 특히 대기업의 경우 다음과 같은 문제가 발생할 수 있다는 것입니다. 매우 DevSecOps를 표준으로 구현하는 것과는 거리가 멀다.2017년에는 프로젝트 관리 연구소의 연구 51% 의 조직이 여전히 소프트웨어 개발에 Waterfall을 사용하고 있는 것으로 나타났습니다.이 연구는 이제 5년이 지났지만 대기업에서 얼마나 점진적인 변화가 일어날 수 있는지를 알기에 최신 보안 중심 방법론으로의 급격한 전환은 불가능할 것입니다.이러한 레거시 프로세스는 사이버 위협으로부터 보호하기 위한 포괄적인 전략으로 모든 기반을 다루려는 보안 전문가들에게 힘든 싸움을 안겨줄 수 있습니다. 개발자와 그들의 요구 사항을 이러한 환경에 맞게 개조하는 것은 어려운 일입니다.

하지만 우리는 이것을 변명할 수 없습니다.비즈니스 보안 전문가는 개발자를 개선된 전략으로 활용할 수 있습니다. 개발자는 자신의 요구 사항을 숙지하고 이를 방어 전략의 일부로 간주하기만 하면 됩니다.이들에게는 포괄적인 교육이 필요하며 보안에 대한 모든 책임은 기술 스택과 워크플로우와 관련하여 구현되어야 합니다.

보안 코딩 = “너무 어려운” 바구니?

Evans Data의 연구에 따르면 무려 86% 의 개발자가 보안 코딩을 연습하는 데 어려움을 겪고 있으며, 개발자 관리자의 92% 는 팀에 보안 프레임워크에 대한 추가 교육이 필요하다고 인정했습니다.걱정스럽게도 응답자의 48% 가 고의로 코드에 취약점을 남겼다고 인정했습니다.

이것은 매우 우려스러운 그림을 그립니다.일반적으로 개발자들은 적절한 교육을 자주 받지 못하고 있으며, 좋은 보안 관행과 위생에 충분히 노출되어 있지도 않은 것 같습니다.줄거리를 읽다 보면 문제의 핵심이 더 분명해집니다. 개발자가 작업에서 보안을 고려하는 것이 우선 순위가 아니라는 점이죠.게다가 교육을 받는다고 해서 자신감이나 실용적인 기술이 쌓이지는 않을 뿐만 아니라 취약한 코드를 배포하기로 한 결정이 미치는 영향을 이해하는 데도 도움이 되지 않습니다.

콜로니얼 파이프라인 (Colonial Pipeline) 랜섬웨어 공격은 지난 한 해 동안 가장 파괴적인 공급망 보안 사건 중 하나로, 미국 동부 해안의 가스 공급의 절반이 미정 기간 동안 차단될 것이라는 공포를 불러일으켰습니다.다행스럽게도 이러한 공격은 빠르게 복구되어 실행되었지만 커뮤니티에서 크게 우려하지 않은 것은 아니었습니다.일반 대중이 사이버 사고가 발생하여 소프트웨어 중심이라고 생각하지 않는 물리적 세계의 요소에 심각한 영향을 미치거나 사이버 공격의 위험이 발생할 가능성에 직면하게 된 순간이었습니다.이 모든 혼란은 패치가 적용되지 않은 두 가지 오래된 취약점 때문에 가능했는데, 그 중 하나는 교활하지만 널리 알려진 SQL 주입이었습니다.개발자들이 취약한 코드를 배포하기로 결정했을 때 실제로 어떤 문제가 발생했는지 안다면, 그러한 위험이 감수할 수 있는 비즈니스 위험이 없다는 것을 금방 알 수 있을 것입니다.

기능적인 “P-P-T”는 개발자의 몫이 아닙니다.

사람, 프로세스, 도구라는 유명한 “골든 트라이앵글”은 신중하게 고려된 전략 없이는 달성할 수 없으며, 개발자는 자신의 요구와 과제를 고려하지 않고는 제대로 작동하는 보안 프로세스에 동화될 수 없습니다.

개발자 중심의 보안을 강화하기 위해서는 상당한 문화 변화가 필요할 것이며, 엔지니어와 보안 팀 모두가 더 명확하게 이해할 수 있도록 하는 교육 경로에서 시작됩니다.