TL; DR
최근 몇 년 동안 기술 업계에서는 소프트웨어 개발에서 "좌측 이동"이라는 개념을 열렬히 옹호하면서 보안 관행을 개발 수명 주기에 조기에 통합할 것을 옹호했습니다. 이 움직임은 개발자에게 프로젝트 시작부터 코드 보안을 보장할 책임을 부여하는 것을 목표로 합니다. 그러나 이 접근 방식의 의도는 고상하지만 현실은 더 미묘한 그림을 그립니다. 소프트웨어 공급망 보안 부적합한 것으로 판명됩니다. 이 기사에서는 보완적인 균형 조정 접근 방식, 즉 CISO가 지시하는 SDLC 가드레일(SDLC의 보안 정책을 관리하거나 시행하는 자동 제어 조치)을 제시하겠습니다.
누가 Shift-Left 내 치즈를 남겼나요?
본질적으로 Shift-Left 패러다임은 개발 초기 단계에서 보안 문제를 해결하는 것을 목표로 하며 개발자가 코드 내에 보안 조치를 사전에 포함할 것을 기대합니다. 개발자가 코드를 작성하고 배포할 때 취약점을 식별하고 보안 제어를 구현하는 임무를 맡는다는 것은 매력적인 이데올로기입니다.
그러나 이러한 이상적인 접근 방식은 실제 구현에서 심각한 문제에 직면합니다. 개발자는 코딩에 능숙하지만 보안 기술 및 모범 사례에 대한 포괄적인 전문 지식이 부족할 수 있습니다. 이들의 주요 초점은 기능적 요구 사항을 충족하는 데 있으며, 끊임없이 진화하는 사이버 보안 환경에 대한 철저한 이해를 기대하는 것은 비현실적입니다.
또한, 시간 제약과 프로젝트 압박으로 인해 보안과 기한 준수 사이에서 상충 관계가 발생하는 경우가 많습니다. 기능을 신속하게 제공하기 위해 서둘러 개발자는 잠재적인 보안 허점을 실수로 간과하거나 보안 수준이 낮은 코딩 방식을 사용하여 이후 단계까지 취약점을 해결하지 못한 채로 남겨둘 수 있습니다. 결국 KPI는 속도 지향적이며 보안은 대다수에게 항상 두 번째입니다.
CI/CD 가드레일 입력
CI/CD(지속적 통합/지속적 배포) 파이프라인에서 보안 "가드레일" 구현의 필요성이 분명해지는 곳입니다. 가드레일은 개발 파이프라인에 포함된 자동화된 체크포인트 역할을 하여 보안 조치가 수동 개입이나 개별 개발자의 전문 지식 또는 동기에만 의존하지 않도록 보장합니다.
Guardrails는 소프트웨어 개발 수명주기(SDLC) 전반에 걸쳐 보안 표준, 정책 및 규칙을 지속적으로 모니터링하고 시행하는 사전 예방적인 문지기 역할을 합니다. 이러한 자동화된 검사는 불량 패키지 차단, 심각한 취약점이 포함된 코드 중지, 정적 코드 분석 테스트 실패 또는 문제가 있는 종속성, 규정 준수 표준 준수 또는 SDLC 정책 보안(예: 코드 모든 커밋을 검토합니다.)
코드형 정책 개념을 사용하면 가드레일로 구현될 것으로 상상할 수 있는 거의 모든 규칙을 만들 수 있습니다. 다음은 가드레일 규칙의 몇 가지 예입니다. NIST 800-204D:
예시적인 가드레일 규칙:
- 개발자 워크스테이션
- 개발자 워크스테이션의 엔드포인트 보안 제품군 확인
- SCM
- 분기 보호 규칙 확인: 여러\특정 검토 시행
- 허용된 직원만 CI 파일을 수정하는지 확인하세요.
- 비밀 스캐닝이 이루어지고 비밀이 감지되지 않는지 확인하세요.
- CI
- 코드 스캔이 제대로 이루어졌는지 확인하세요.
- 코드 스캔 결과가 사전 정의된 막대 아래에 있는지 확인
- 종속성
- 오픈소스 라이선스를 확인하세요.
- 오픈소스 취약점이 조직 정책을 준수하는지 확인하세요.
- 유물
- 올바른 ID가 아티팩트에 서명하는지 확인하십시오.
- 최종 아티팩트 취약점을 확인합니다.
난간이 아닌 난간
가드레일을 CI/CD 파이프라인에 통합함으로써 조직은 포괄적인 보안 조치를 보장하기 위해 개발자에게만 의존하지 않고도 보안 프로토콜을 체계적으로 시행하고 안전한 제품을 만들 수 있습니다. 개발자가 개발 속도를 위해 보안 조치를 우회할 수 있다는 점을 고려하면 가드레일 접근 방식은 이러한 결정을 불가능하거나 최소한 가시적으로 만들므로 단일 빌드 수준 모두에서 고려할 수 있습니다(예: 아티팩트 신뢰성 결정). ) 및 조직 수준(조직의 개발자에게 무엇을 기대할 수 있고 기대할 수 없는지 이해)에서. 자동화된 도구는 새 버전이 프로덕션 환경에 출시되거나 클라이언트에 전달되기 전에 잠재적인 취약점이나 비준수 문제를 표시하거나 차단할 수도 있습니다. 결국 보안 문제를 제품 출시 이후보다 개발 단계에서 처리하는 것이 실제로 훨씬 쉽고 빠르며 저렴합니다.
좌파로의 전환이 개발자의 보안 관행 참여를 장려하는 동시에 다른 이해관계자(보안 전문가, DevOps 엔지니어, 품질 보증 팀)의 역할을 면제해서는 안 된다는 점을 인식하는 것이 중요합니다. 제품 보안, AppSec, DevSecOps 또는 CISO라면 개발자에 대한 책임을 "왼쪽으로 이동"한다고 해서 책임이 사라지는 것은 아니라는 점을 이미 알고 계실 것입니다. 대부분의 CISO와 그 팀은 R&D 출신이 아니기 때문에 역사적으로 소프트웨어 개발 환경은 그들의 눈에 띄지 않았습니다. 그들은 전통적으로 운영 보안, 네트워크 보안 및 조직 간 연결에 중점을 두었습니다. 가드레일 접근 방식은 CISO를 개발 환경의 황량한 서부로 "섬세하게" 유도하여 그들이 담당하는 대상에 대한 통제권을 다시 얻는 방법입니다.. "섬세하게"라는 말은 "협력적으로"를 의미합니다. 제품 보안은 보안팀과 개발팀의 공동 노력이므로 개발 속도를 방해하지 않고 잠재적인 보안 위협으로부터 CI/CD 파이프라인을 강화하는 강력한 가드레일을 설계하고 구현하려면 이러한 엔터티 간의 협업이 필수적입니다.
CI/CD 파이프라인의 가드레일 설정과 왼쪽 이동 원칙의 통합은 좋은 균형을 이루고 있습니다. 개발자는 보안 코드를 작성하고 기본 보안 원칙을 이해할 책임이 있으며, 보안 팀은 제품 출시를 위해 충족해야 하는 표준을 결정합니다. 그런 다음 가드레일은 그에 따라 도구와 프로세스로 자동화되어 안전망 역할을 하며 보안 표준과 SDLC 정책을 지속적으로 모니터링하고 강화합니다. 가드레일은 설계 및 기본적으로 안전한 제품을 향한 필수 단계입니다.
최대 포장
결론적으로, 의도는 좋지만 왼쪽으로 이동하는 개념은 개발자 참여만으로 포괄적인 소프트웨어 보안을 보장하기에는 부족합니다. 최종 소프트웨어 아티팩트의 무결성과 신뢰성을 강화하려면 조직은 CI/CD 파이프라인 내에서 가드레일 구현을 수용해야 합니다. 이러한 결합된 접근 방식은 소프트웨어의 보안 상태를 향상시킬 뿐만 아니라 개발자, 보안 전문가 및 자동화 도구가 보안 소프트웨어를 생성한다는 공통 목표를 향해 시너지 효과를 발휘하는 협업 환경을 조성합니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
