정부 공급망 파이프라인의 사이버 취약성에 대한 베일 제거
이 기사의 한 버전이 에 게재되었습니다. 테크 크런치.여기에서 업데이트 및 신디케이트되었습니다.
이름을 붙일 수 없는 해에도 충분한 혼란이 없었던 것처럼 2021년은 기록상 최악의 데이터 유출 사건으로 미국 정부의 귀가 먹먹해질 정도로 시작됐습니다.SolarWinds 사고는 파괴적이고 정교한 국가 공격으로, 몇몇 정부 부처와 대규모 조직을 공포에 빠뜨리고 엔드포인트를 확보하기 위해 분주하게 움직였습니다.SolarWinds 소프트웨어의 거의 모든 최종 사용자가 피해를 입었고, 이번 사건을 통해 소프트웨어 공급망의 사이버 보안과 방어가 매우 중요하다는 것이 분명해졌습니다.
사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 의미하는 바는 무엇일까요?
일반 개발 팀의 사이버 보안 현황
매년 수십억 라인의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있습니다. 이는 점진적인 디지털 라이프스타일로 인해 수요가 증가함에 따라 증가하고 있습니다.전 세계 개발자 인구는 다음과 같이 급증할 것으로 예상됩니다. 2024년까지 거의 2천 9백만그리고 현재로서는 안전한 코딩 능력을 평가하고 인증하기 위한 공식 인증은 없습니다.그렇다고 모든 개발자가 안전하지 않은 코드를 만들거나 재사용한다는 말은 아니지만, 우리가 데이터를 신뢰할 수 있는 소프트웨어에 기본적인 보안 약점이 도입될 수 있는 위험은 의심할 여지 없이 존재합니다.
개발자는 가능한 한 빨리 기능을 만들고 코드를 출시할 수 있는지 평가받습니다.대부분의 조직에서 보안이 성공의 벤치마크가 되지는 않았지만, 소프트웨어 개발 초기 단계에서 일반적인 보안 버그를 방지할 수 있는 잠재력을 깨닫는 기업이 늘어남에 따라 이러한 인식이 바뀌기 시작했습니다.하지만 구현과 구현은 서로 다른 문제이고, 대부분의 3차 개발 과정에서는 보안 코딩 관행에 대한 배경 정보를 생략하기 때문에 부족한 부분을 보충하는 것은 개발자의 작업장에 달려 있는 경우가 많습니다.기술 구축과 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다.따라서 기술 개발 부족으로 인해 취약성이 반복되는 악순환이 끊어지지 않습니다.
당연히 전 세계의 사이버 보안 문제를 해결하는 것은 일반 소프트웨어 개발자의 책임이 아닙니다. 결국 조직에서 비용이 많이 드는 보안 전문가를 고용하는 데에는 이유가 있습니다.하지만 보안 전문가는 부족하기 때문에 개발자들이 이러한 부담을 줄이는 데 큰 역할을 할 수 있습니다.
하지만 치명적인 사이버 공격을 방지하는 측면에서 우리와 중요 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떻게 될까요?이를 위해서는 최소한 소프트웨어 조달의 현재 상태를 바꿔야 할 것입니다.
안전한 소프트웨어 공급망을 가로막는 위험
체인은 가장 약한 연결 고리만큼만 강하다는 지겨운 격언은 안타깝게도 소프트웨어 공급에 있어서도 마찬가지입니다.회사가 보안 모범 사례 강화, 개발자 기술 향상에 대한 투자, 기능적인 DevSecOps 환경으로의 전환 (즉, 소프트웨어를 최대한 안전하게 만드는 데 대한 책임을 공유하는 모든 사람) 으로 전환했더라도 상관 없습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하고 그에 따른 결과를 감수하게 됩니다.
물론 보안 팀은 기술 스택에 추가된 서드파티의 안전성을 평가하는 데 도움을 주어야 합니다. 하지만 솔루션 중에서 선택할 수 있는 옵션이 거의 없기 때문에 비즈니스 요구 사항을 기반으로 결정을 내릴 수 있습니다.이 시점에서 이는 신뢰를 쌓는 행위가 될 수 있습니다.공급업체도 귀사만큼 보안에 신경을 많이 쓰나요?그리고 당신만이 이해할 수 있는 위험과 보호해야 할 자산을 벤더가 실제로 평가할 수 있을까요?
투명성은 공급업체 소프트웨어 추가의 보안 가능성을 평가하는 데 있어 매우 중요한 요소입니다.그들도 그런가? 자체 보안 관행을 미리 파악합니다.?데이터를 안전하게 유지하기 위한 접근 방식에 자부심을 가져야 하며, 이를 최우선 과제로 삼아야 합니다.보안 관행이 어디에도 게시되어 있지 않거나 사용할 수 있는 정보가 없는 경우 보안을 최우선으로 고려하지 않을 가능성이 높습니다.공급업체는 기술 관련 질문에 답변할 수 있어야 하며 다음과 같은 독립 인증을 받아야 합니다. ISO27001 그리고 SOC2도 아프지 않을 것입니다.또한 내부 실사 및 보안 관행의 일환으로 “내부적으로 검토”하고 취약점을 검사할 수 없다면 잊어버리세요.
수요로 인해 소프트웨어 요구 사항의 구현이 빠르게 진행됨에 따라, 특히 공급업체 코드를 기존 시스템에 통합하여 새로운 컨텍스트에서 작업을 수행하는 경우 공급업체와 구매자 모두 업계 최고의 입지를 확보해야 합니다. 둘 다 출시하기 전에 일반적인 보안 버그와 결함을 찾아낼 수 있도록 개발자를 현장에 배치해야 합니다.기존의 기술 솔루션 스파이더 웹에 새로운 기능을 추가할 경우 수백, 수천 개의 종속성이 손상될 수 있으며, 작은 실패 하나가 심각한 실패로 이어질 수 있습니다.
그렇다면 해결책은 무엇일까요?모든 것을 처음부터 사내에서 코딩하시겠어요?1998년이었다면 말이 될 수도 있겠네요.하지만 더 이상 지브스에게 가장 가까운 세차장이 어디인지 묻지 않는 것처럼, 우리도 오늘날의 상황에 맞는 현실적인 안전 장치를 구현해야 합니다.
아직 은총알은 없지만 해결책이 있습니다
구매자의 경우 공급업체 소프트웨어 및 개발 관행에 대한 보안 평가를 전체 보안 프로그램 및 위험 완화 계획의 우선 순위로 삼아야 합니다.구매자의 인증, 사례 및 개발자의 보안 평판에 대해 질문하세요.
공급업체 (및 소프트웨어를 만드는 모든 회사) 는 보안이 최우선임을 입증할 준비가 되어 있어야 하며 기술 향상에 집중해야 합니다. 보안에 능숙한 개발자 수요가 많으며 적합한 도구 및 지원기존 팀에서 구축할 수 있으며 일반적인 취약점으로 인한 공격을 방어할 수 있습니다.하지만 기존 트레이닝을 그들에게 던지지는 마세요.기존 워크플로를 보완하는 보안 도구를 사용하여 번창할 시간을 주세요.최대한 쉽게 만들고 비즈니스를 지원하는 코드 사이에서 이러한 성가신 버그가 사라지기 시작하는 것을 지켜보세요.
결론은 소프트웨어 위험이 공급망의 일부일 경우 즉시 악화되어 취약한 구성 요소가 활용된 모든 사용자와 시스템에 영향을 미친다는 것입니다.공급업체가 소프트웨어를 구현하는 회사만큼 보안에 대해 진지하지 않거나 공급업체와 조직 모두 보안 프로그램이 부족한 경우 SolarWinds와 같은 더 파괴적이고 광범위한 공급망 공격은 필연적으로 표준이 될 것이며 이는 모두에게 심각한 문제입니다.
최고 경영자, 회장 겸 공동 설립자
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.
이 기사의 한 버전이 에 게재되었습니다. 테크 크런치.여기에서 업데이트 및 신디케이트되었습니다.
이름을 붙일 수 없는 해에도 충분한 혼란이 없었던 것처럼 2021년은 기록상 최악의 데이터 유출 사건으로 미국 정부의 귀가 먹먹해질 정도로 시작됐습니다.SolarWinds 사고는 파괴적이고 정교한 국가 공격으로, 몇몇 정부 부처와 대규모 조직을 공포에 빠뜨리고 엔드포인트를 확보하기 위해 분주하게 움직였습니다.SolarWinds 소프트웨어의 거의 모든 최종 사용자가 피해를 입었고, 이번 사건을 통해 소프트웨어 공급망의 사이버 보안과 방어가 매우 중요하다는 것이 분명해졌습니다.
사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 의미하는 바는 무엇일까요?
일반 개발 팀의 사이버 보안 현황
매년 수십억 라인의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있습니다. 이는 점진적인 디지털 라이프스타일로 인해 수요가 증가함에 따라 증가하고 있습니다.전 세계 개발자 인구는 다음과 같이 급증할 것으로 예상됩니다. 2024년까지 거의 2천 9백만그리고 현재로서는 안전한 코딩 능력을 평가하고 인증하기 위한 공식 인증은 없습니다.그렇다고 모든 개발자가 안전하지 않은 코드를 만들거나 재사용한다는 말은 아니지만, 우리가 데이터를 신뢰할 수 있는 소프트웨어에 기본적인 보안 약점이 도입될 수 있는 위험은 의심할 여지 없이 존재합니다.
개발자는 가능한 한 빨리 기능을 만들고 코드를 출시할 수 있는지 평가받습니다.대부분의 조직에서 보안이 성공의 벤치마크가 되지는 않았지만, 소프트웨어 개발 초기 단계에서 일반적인 보안 버그를 방지할 수 있는 잠재력을 깨닫는 기업이 늘어남에 따라 이러한 인식이 바뀌기 시작했습니다.하지만 구현과 구현은 서로 다른 문제이고, 대부분의 3차 개발 과정에서는 보안 코딩 관행에 대한 배경 정보를 생략하기 때문에 부족한 부분을 보충하는 것은 개발자의 작업장에 달려 있는 경우가 많습니다.기술 구축과 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다.따라서 기술 개발 부족으로 인해 취약성이 반복되는 악순환이 끊어지지 않습니다.
당연히 전 세계의 사이버 보안 문제를 해결하는 것은 일반 소프트웨어 개발자의 책임이 아닙니다. 결국 조직에서 비용이 많이 드는 보안 전문가를 고용하는 데에는 이유가 있습니다.하지만 보안 전문가는 부족하기 때문에 개발자들이 이러한 부담을 줄이는 데 큰 역할을 할 수 있습니다.
하지만 치명적인 사이버 공격을 방지하는 측면에서 우리와 중요 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떻게 될까요?이를 위해서는 최소한 소프트웨어 조달의 현재 상태를 바꿔야 할 것입니다.
안전한 소프트웨어 공급망을 가로막는 위험
체인은 가장 약한 연결 고리만큼만 강하다는 지겨운 격언은 안타깝게도 소프트웨어 공급에 있어서도 마찬가지입니다.회사가 보안 모범 사례 강화, 개발자 기술 향상에 대한 투자, 기능적인 DevSecOps 환경으로의 전환 (즉, 소프트웨어를 최대한 안전하게 만드는 데 대한 책임을 공유하는 모든 사람) 으로 전환했더라도 상관 없습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하고 그에 따른 결과를 감수하게 됩니다.
물론 보안 팀은 기술 스택에 추가된 서드파티의 안전성을 평가하는 데 도움을 주어야 합니다. 하지만 솔루션 중에서 선택할 수 있는 옵션이 거의 없기 때문에 비즈니스 요구 사항을 기반으로 결정을 내릴 수 있습니다.이 시점에서 이는 신뢰를 쌓는 행위가 될 수 있습니다.공급업체도 귀사만큼 보안에 신경을 많이 쓰나요?그리고 당신만이 이해할 수 있는 위험과 보호해야 할 자산을 벤더가 실제로 평가할 수 있을까요?
투명성은 공급업체 소프트웨어 추가의 보안 가능성을 평가하는 데 있어 매우 중요한 요소입니다.그들도 그런가? 자체 보안 관행을 미리 파악합니다.?데이터를 안전하게 유지하기 위한 접근 방식에 자부심을 가져야 하며, 이를 최우선 과제로 삼아야 합니다.보안 관행이 어디에도 게시되어 있지 않거나 사용할 수 있는 정보가 없는 경우 보안을 최우선으로 고려하지 않을 가능성이 높습니다.공급업체는 기술 관련 질문에 답변할 수 있어야 하며 다음과 같은 독립 인증을 받아야 합니다. ISO27001 그리고 SOC2도 아프지 않을 것입니다.또한 내부 실사 및 보안 관행의 일환으로 “내부적으로 검토”하고 취약점을 검사할 수 없다면 잊어버리세요.
수요로 인해 소프트웨어 요구 사항의 구현이 빠르게 진행됨에 따라, 특히 공급업체 코드를 기존 시스템에 통합하여 새로운 컨텍스트에서 작업을 수행하는 경우 공급업체와 구매자 모두 업계 최고의 입지를 확보해야 합니다. 둘 다 출시하기 전에 일반적인 보안 버그와 결함을 찾아낼 수 있도록 개발자를 현장에 배치해야 합니다.기존의 기술 솔루션 스파이더 웹에 새로운 기능을 추가할 경우 수백, 수천 개의 종속성이 손상될 수 있으며, 작은 실패 하나가 심각한 실패로 이어질 수 있습니다.
그렇다면 해결책은 무엇일까요?모든 것을 처음부터 사내에서 코딩하시겠어요?1998년이었다면 말이 될 수도 있겠네요.하지만 더 이상 지브스에게 가장 가까운 세차장이 어디인지 묻지 않는 것처럼, 우리도 오늘날의 상황에 맞는 현실적인 안전 장치를 구현해야 합니다.
아직 은총알은 없지만 해결책이 있습니다
구매자의 경우 공급업체 소프트웨어 및 개발 관행에 대한 보안 평가를 전체 보안 프로그램 및 위험 완화 계획의 우선 순위로 삼아야 합니다.구매자의 인증, 사례 및 개발자의 보안 평판에 대해 질문하세요.
공급업체 (및 소프트웨어를 만드는 모든 회사) 는 보안이 최우선임을 입증할 준비가 되어 있어야 하며 기술 향상에 집중해야 합니다. 보안에 능숙한 개발자 수요가 많으며 적합한 도구 및 지원기존 팀에서 구축할 수 있으며 일반적인 취약점으로 인한 공격을 방어할 수 있습니다.하지만 기존 트레이닝을 그들에게 던지지는 마세요.기존 워크플로를 보완하는 보안 도구를 사용하여 번창할 시간을 주세요.최대한 쉽게 만들고 비즈니스를 지원하는 코드 사이에서 이러한 성가신 버그가 사라지기 시작하는 것을 지켜보세요.
결론은 소프트웨어 위험이 공급망의 일부일 경우 즉시 악화되어 취약한 구성 요소가 활용된 모든 사용자와 시스템에 영향을 미친다는 것입니다.공급업체가 소프트웨어를 구현하는 회사만큼 보안에 대해 진지하지 않거나 공급업체와 조직 모두 보안 프로그램이 부족한 경우 SolarWinds와 같은 더 파괴적이고 광범위한 공급망 공격은 필연적으로 표준이 될 것이며 이는 모두에게 심각한 문제입니다.
이 기사의 한 버전이 에 게재되었습니다. 테크 크런치.여기에서 업데이트 및 신디케이트되었습니다.
이름을 붙일 수 없는 해에도 충분한 혼란이 없었던 것처럼 2021년은 기록상 최악의 데이터 유출 사건으로 미국 정부의 귀가 먹먹해질 정도로 시작됐습니다.SolarWinds 사고는 파괴적이고 정교한 국가 공격으로, 몇몇 정부 부처와 대규모 조직을 공포에 빠뜨리고 엔드포인트를 확보하기 위해 분주하게 움직였습니다.SolarWinds 소프트웨어의 거의 모든 최종 사용자가 피해를 입었고, 이번 사건을 통해 소프트웨어 공급망의 사이버 보안과 방어가 매우 중요하다는 것이 분명해졌습니다.
사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 의미하는 바는 무엇일까요?
일반 개발 팀의 사이버 보안 현황
매년 수십억 라인의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있습니다. 이는 점진적인 디지털 라이프스타일로 인해 수요가 증가함에 따라 증가하고 있습니다.전 세계 개발자 인구는 다음과 같이 급증할 것으로 예상됩니다. 2024년까지 거의 2천 9백만그리고 현재로서는 안전한 코딩 능력을 평가하고 인증하기 위한 공식 인증은 없습니다.그렇다고 모든 개발자가 안전하지 않은 코드를 만들거나 재사용한다는 말은 아니지만, 우리가 데이터를 신뢰할 수 있는 소프트웨어에 기본적인 보안 약점이 도입될 수 있는 위험은 의심할 여지 없이 존재합니다.
개발자는 가능한 한 빨리 기능을 만들고 코드를 출시할 수 있는지 평가받습니다.대부분의 조직에서 보안이 성공의 벤치마크가 되지는 않았지만, 소프트웨어 개발 초기 단계에서 일반적인 보안 버그를 방지할 수 있는 잠재력을 깨닫는 기업이 늘어남에 따라 이러한 인식이 바뀌기 시작했습니다.하지만 구현과 구현은 서로 다른 문제이고, 대부분의 3차 개발 과정에서는 보안 코딩 관행에 대한 배경 정보를 생략하기 때문에 부족한 부분을 보충하는 것은 개발자의 작업장에 달려 있는 경우가 많습니다.기술 구축과 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다.따라서 기술 개발 부족으로 인해 취약성이 반복되는 악순환이 끊어지지 않습니다.
당연히 전 세계의 사이버 보안 문제를 해결하는 것은 일반 소프트웨어 개발자의 책임이 아닙니다. 결국 조직에서 비용이 많이 드는 보안 전문가를 고용하는 데에는 이유가 있습니다.하지만 보안 전문가는 부족하기 때문에 개발자들이 이러한 부담을 줄이는 데 큰 역할을 할 수 있습니다.
하지만 치명적인 사이버 공격을 방지하는 측면에서 우리와 중요 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떻게 될까요?이를 위해서는 최소한 소프트웨어 조달의 현재 상태를 바꿔야 할 것입니다.
안전한 소프트웨어 공급망을 가로막는 위험
체인은 가장 약한 연결 고리만큼만 강하다는 지겨운 격언은 안타깝게도 소프트웨어 공급에 있어서도 마찬가지입니다.회사가 보안 모범 사례 강화, 개발자 기술 향상에 대한 투자, 기능적인 DevSecOps 환경으로의 전환 (즉, 소프트웨어를 최대한 안전하게 만드는 데 대한 책임을 공유하는 모든 사람) 으로 전환했더라도 상관 없습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하고 그에 따른 결과를 감수하게 됩니다.
물론 보안 팀은 기술 스택에 추가된 서드파티의 안전성을 평가하는 데 도움을 주어야 합니다. 하지만 솔루션 중에서 선택할 수 있는 옵션이 거의 없기 때문에 비즈니스 요구 사항을 기반으로 결정을 내릴 수 있습니다.이 시점에서 이는 신뢰를 쌓는 행위가 될 수 있습니다.공급업체도 귀사만큼 보안에 신경을 많이 쓰나요?그리고 당신만이 이해할 수 있는 위험과 보호해야 할 자산을 벤더가 실제로 평가할 수 있을까요?
투명성은 공급업체 소프트웨어 추가의 보안 가능성을 평가하는 데 있어 매우 중요한 요소입니다.그들도 그런가? 자체 보안 관행을 미리 파악합니다.?데이터를 안전하게 유지하기 위한 접근 방식에 자부심을 가져야 하며, 이를 최우선 과제로 삼아야 합니다.보안 관행이 어디에도 게시되어 있지 않거나 사용할 수 있는 정보가 없는 경우 보안을 최우선으로 고려하지 않을 가능성이 높습니다.공급업체는 기술 관련 질문에 답변할 수 있어야 하며 다음과 같은 독립 인증을 받아야 합니다. ISO27001 그리고 SOC2도 아프지 않을 것입니다.또한 내부 실사 및 보안 관행의 일환으로 “내부적으로 검토”하고 취약점을 검사할 수 없다면 잊어버리세요.
수요로 인해 소프트웨어 요구 사항의 구현이 빠르게 진행됨에 따라, 특히 공급업체 코드를 기존 시스템에 통합하여 새로운 컨텍스트에서 작업을 수행하는 경우 공급업체와 구매자 모두 업계 최고의 입지를 확보해야 합니다. 둘 다 출시하기 전에 일반적인 보안 버그와 결함을 찾아낼 수 있도록 개발자를 현장에 배치해야 합니다.기존의 기술 솔루션 스파이더 웹에 새로운 기능을 추가할 경우 수백, 수천 개의 종속성이 손상될 수 있으며, 작은 실패 하나가 심각한 실패로 이어질 수 있습니다.
그렇다면 해결책은 무엇일까요?모든 것을 처음부터 사내에서 코딩하시겠어요?1998년이었다면 말이 될 수도 있겠네요.하지만 더 이상 지브스에게 가장 가까운 세차장이 어디인지 묻지 않는 것처럼, 우리도 오늘날의 상황에 맞는 현실적인 안전 장치를 구현해야 합니다.
아직 은총알은 없지만 해결책이 있습니다
구매자의 경우 공급업체 소프트웨어 및 개발 관행에 대한 보안 평가를 전체 보안 프로그램 및 위험 완화 계획의 우선 순위로 삼아야 합니다.구매자의 인증, 사례 및 개발자의 보안 평판에 대해 질문하세요.
공급업체 (및 소프트웨어를 만드는 모든 회사) 는 보안이 최우선임을 입증할 준비가 되어 있어야 하며 기술 향상에 집중해야 합니다. 보안에 능숙한 개발자 수요가 많으며 적합한 도구 및 지원기존 팀에서 구축할 수 있으며 일반적인 취약점으로 인한 공격을 방어할 수 있습니다.하지만 기존 트레이닝을 그들에게 던지지는 마세요.기존 워크플로를 보완하는 보안 도구를 사용하여 번창할 시간을 주세요.최대한 쉽게 만들고 비즈니스를 지원하는 코드 사이에서 이러한 성가신 버그가 사라지기 시작하는 것을 지켜보세요.
결론은 소프트웨어 위험이 공급망의 일부일 경우 즉시 악화되어 취약한 구성 요소가 활용된 모든 사용자와 시스템에 영향을 미친다는 것입니다.공급업체가 소프트웨어를 구현하는 회사만큼 보안에 대해 진지하지 않거나 공급업체와 조직 모두 보안 프로그램이 부족한 경우 SolarWinds와 같은 더 파괴적이고 광범위한 공급망 공격은 필연적으로 표준이 될 것이며 이는 모두에게 심각한 문제입니다.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
최고 경영자, 회장 겸 공동 설립자
피터 댄히외는 보안 컨설턴트로 12년 이상 경력을 쌓았으며, 조직, 시스템 및 개인의 보안 취약점을 타겟팅하고 평가하는 방법에 대한 공격 기법을 가르치는 SANS의 수석 강사로 8년 이상 활동한 세계적으로 인정받는 보안 전문가입니다. 2016년에는 호주에서 가장 멋진 기술자 중 한 명으로 선정(비즈니스 인사이더)되었고, 올해의 사이버 보안 전문가(AISA - 호주 정보 보안 협회)로 선정되었으며, GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA 자격증을 보유하고 있습니다.
이 기사의 한 버전이 에 게재되었습니다. 테크 크런치.여기에서 업데이트 및 신디케이트되었습니다.
이름을 붙일 수 없는 해에도 충분한 혼란이 없었던 것처럼 2021년은 기록상 최악의 데이터 유출 사건으로 미국 정부의 귀가 먹먹해질 정도로 시작됐습니다.SolarWinds 사고는 파괴적이고 정교한 국가 공격으로, 몇몇 정부 부처와 대규모 조직을 공포에 빠뜨리고 엔드포인트를 확보하기 위해 분주하게 움직였습니다.SolarWinds 소프트웨어의 거의 모든 최종 사용자가 피해를 입었고, 이번 사건을 통해 소프트웨어 공급망의 사이버 보안과 방어가 매우 중요하다는 것이 분명해졌습니다.
사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 의미하는 바는 무엇일까요?
일반 개발 팀의 사이버 보안 현황
매년 수십억 라인의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있습니다. 이는 점진적인 디지털 라이프스타일로 인해 수요가 증가함에 따라 증가하고 있습니다.전 세계 개발자 인구는 다음과 같이 급증할 것으로 예상됩니다. 2024년까지 거의 2천 9백만그리고 현재로서는 안전한 코딩 능력을 평가하고 인증하기 위한 공식 인증은 없습니다.그렇다고 모든 개발자가 안전하지 않은 코드를 만들거나 재사용한다는 말은 아니지만, 우리가 데이터를 신뢰할 수 있는 소프트웨어에 기본적인 보안 약점이 도입될 수 있는 위험은 의심할 여지 없이 존재합니다.
개발자는 가능한 한 빨리 기능을 만들고 코드를 출시할 수 있는지 평가받습니다.대부분의 조직에서 보안이 성공의 벤치마크가 되지는 않았지만, 소프트웨어 개발 초기 단계에서 일반적인 보안 버그를 방지할 수 있는 잠재력을 깨닫는 기업이 늘어남에 따라 이러한 인식이 바뀌기 시작했습니다.하지만 구현과 구현은 서로 다른 문제이고, 대부분의 3차 개발 과정에서는 보안 코딩 관행에 대한 배경 정보를 생략하기 때문에 부족한 부분을 보충하는 것은 개발자의 작업장에 달려 있는 경우가 많습니다.기술 구축과 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다.따라서 기술 개발 부족으로 인해 취약성이 반복되는 악순환이 끊어지지 않습니다.
당연히 전 세계의 사이버 보안 문제를 해결하는 것은 일반 소프트웨어 개발자의 책임이 아닙니다. 결국 조직에서 비용이 많이 드는 보안 전문가를 고용하는 데에는 이유가 있습니다.하지만 보안 전문가는 부족하기 때문에 개발자들이 이러한 부담을 줄이는 데 큰 역할을 할 수 있습니다.
하지만 치명적인 사이버 공격을 방지하는 측면에서 우리와 중요 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떻게 될까요?이를 위해서는 최소한 소프트웨어 조달의 현재 상태를 바꿔야 할 것입니다.
안전한 소프트웨어 공급망을 가로막는 위험
체인은 가장 약한 연결 고리만큼만 강하다는 지겨운 격언은 안타깝게도 소프트웨어 공급에 있어서도 마찬가지입니다.회사가 보안 모범 사례 강화, 개발자 기술 향상에 대한 투자, 기능적인 DevSecOps 환경으로의 전환 (즉, 소프트웨어를 최대한 안전하게 만드는 데 대한 책임을 공유하는 모든 사람) 으로 전환했더라도 상관 없습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하고 그에 따른 결과를 감수하게 됩니다.
물론 보안 팀은 기술 스택에 추가된 서드파티의 안전성을 평가하는 데 도움을 주어야 합니다. 하지만 솔루션 중에서 선택할 수 있는 옵션이 거의 없기 때문에 비즈니스 요구 사항을 기반으로 결정을 내릴 수 있습니다.이 시점에서 이는 신뢰를 쌓는 행위가 될 수 있습니다.공급업체도 귀사만큼 보안에 신경을 많이 쓰나요?그리고 당신만이 이해할 수 있는 위험과 보호해야 할 자산을 벤더가 실제로 평가할 수 있을까요?
투명성은 공급업체 소프트웨어 추가의 보안 가능성을 평가하는 데 있어 매우 중요한 요소입니다.그들도 그런가? 자체 보안 관행을 미리 파악합니다.?데이터를 안전하게 유지하기 위한 접근 방식에 자부심을 가져야 하며, 이를 최우선 과제로 삼아야 합니다.보안 관행이 어디에도 게시되어 있지 않거나 사용할 수 있는 정보가 없는 경우 보안을 최우선으로 고려하지 않을 가능성이 높습니다.공급업체는 기술 관련 질문에 답변할 수 있어야 하며 다음과 같은 독립 인증을 받아야 합니다. ISO27001 그리고 SOC2도 아프지 않을 것입니다.또한 내부 실사 및 보안 관행의 일환으로 “내부적으로 검토”하고 취약점을 검사할 수 없다면 잊어버리세요.
수요로 인해 소프트웨어 요구 사항의 구현이 빠르게 진행됨에 따라, 특히 공급업체 코드를 기존 시스템에 통합하여 새로운 컨텍스트에서 작업을 수행하는 경우 공급업체와 구매자 모두 업계 최고의 입지를 확보해야 합니다. 둘 다 출시하기 전에 일반적인 보안 버그와 결함을 찾아낼 수 있도록 개발자를 현장에 배치해야 합니다.기존의 기술 솔루션 스파이더 웹에 새로운 기능을 추가할 경우 수백, 수천 개의 종속성이 손상될 수 있으며, 작은 실패 하나가 심각한 실패로 이어질 수 있습니다.
그렇다면 해결책은 무엇일까요?모든 것을 처음부터 사내에서 코딩하시겠어요?1998년이었다면 말이 될 수도 있겠네요.하지만 더 이상 지브스에게 가장 가까운 세차장이 어디인지 묻지 않는 것처럼, 우리도 오늘날의 상황에 맞는 현실적인 안전 장치를 구현해야 합니다.
아직 은총알은 없지만 해결책이 있습니다
구매자의 경우 공급업체 소프트웨어 및 개발 관행에 대한 보안 평가를 전체 보안 프로그램 및 위험 완화 계획의 우선 순위로 삼아야 합니다.구매자의 인증, 사례 및 개발자의 보안 평판에 대해 질문하세요.
공급업체 (및 소프트웨어를 만드는 모든 회사) 는 보안이 최우선임을 입증할 준비가 되어 있어야 하며 기술 향상에 집중해야 합니다. 보안에 능숙한 개발자 수요가 많으며 적합한 도구 및 지원기존 팀에서 구축할 수 있으며 일반적인 취약점으로 인한 공격을 방어할 수 있습니다.하지만 기존 트레이닝을 그들에게 던지지는 마세요.기존 워크플로를 보완하는 보안 도구를 사용하여 번창할 시간을 주세요.최대한 쉽게 만들고 비즈니스를 지원하는 코드 사이에서 이러한 성가신 버그가 사라지기 시작하는 것을 지켜보세요.
결론은 소프트웨어 위험이 공급망의 일부일 경우 즉시 악화되어 취약한 구성 요소가 활용된 모든 사용자와 시스템에 영향을 미친다는 것입니다.공급업체가 소프트웨어를 구현하는 회사만큼 보안에 대해 진지하지 않거나 공급업체와 조직 모두 보안 프로그램이 부족한 경우 SolarWinds와 같은 더 파괴적이고 광범위한 공급망 공격은 필연적으로 표준이 될 것이며 이는 모두에게 심각한 문제입니다.
%20(1).avif)
.avif)
