코드의 보안 취약점
임베디드 시스템의 운영 체제 소프트웨어, 애플리케이션 소프트웨어 또는 펌웨어는 모든 디지털 인프라의 기본 구성 요소입니다. 그러나 디지털화 프로젝트의 가속화 및 마감 기한 압박은 종종 필수적인 정보 보안 측면을 무시하게 만듭니다. 소프트웨어에 대한 개발 요구 사항은 일반적으로 기능 중심적이고 건설적인 측면을 강조하므로 잠재적인 보안 취약성에 대한 파괴적인 관점은 대부분 실제 개발 목표와 정반대입니다. 많은 프로그래머는 사이버 보안에 대한 구조화되고 예리한 관점이 부족합니다.
이러한 상황에서 개발 팀은 비영리 MITRE Corporation이 매년 CVE(Common Vulnerabilities and Exposures) 목록에 게시하는 많은 취약점에서 알 수 있듯이 소프트웨어 코딩을 지속적으로 검토하고 지속적으로 보호하는 데 어려움을 겪습니다. 잘 알려진 소프트웨어 제조업체의 정기적인 보안 패치는 시장에 출시되기 전에 식별하는 것은 고사하고 보안 관련 버그를 닫는 Sisyphean 작업의 지표입니다.
오픈 소스 코드 - 특별한 경우
자체 개발 소프트웨어를 코딩할 때 프로그래머는 오픈 소스 라이브러리 및 모듈에 의존하는 것을 좋아합니다. 실질적인 이점은 분명합니다. 바퀴를 계속해서 재발명할 필요가 없다면 이 기술 향상, 빠른 개발, 개발 비용 절감, 오픈 소스 코드를 통한 투명성 향상, 개방형 표준 및 인터페이스를 통한 높은 상호 운용성 등의 이점을 누릴 수 있습니다. .
또한 오픈 소스의 코드는 많은 사용자에 의해 코드가 검증되었고 오픈 소스 커뮤니티의 스웜 인텔리전스가 빠르고 효율적인 버그 수정을 가능하게 하기 때문에 높은 수준의 보안을 제공한다고 종종 말합니다.
실제로 이 신뢰는 이제 차별화되고 비판적인 방식으로 평가되어야 합니다. 가장 심각한 예는 2021년 11월에 발견된 널리 사용되는 Java 애플리케이션용 로깅 라이브러리 Log4J의 제로데이 보안 취약성 Log4Shell입니다. 독일 연방 정보 보안청(BSI)에서 발행한 적색 경보 수준에 대해 들어 보셨을 것입니다. ) Log4Shell의 경우. Apache Foundation을 통해 안정적으로 작동하는 준표준으로 배포되는 Log4J 라이브러리는 Amazon AWS와 같은 잘 알려진 웹 서비스를 포함하여 2013년 이후 많은 시스템에서 자체적으로 구축되었습니다.
이러한 잘 개발되고 유지 관리되는 라이브러리의 복잡성은 가져오기 개발자가 자신의 결합된 새 개발에서 종종 인식하지 못하지만 공격자가 이를 악용할 수 있는 강력한 기능을 암시적으로 제공합니다.
오픈 소스 구성 요소의 또 다른 불안정 요소는 소위 공급망 공격입니다. 즉, 오픈 소스 커뮤니티의 일부로 가장하고 코드 개발을 지원하는 악의적인 행위자가 의도한 내장 취약점입니다. 이러한 취약점은 해커가 다수의 하위 사용자 조직을 공격할 수 있는 매우 효율적인 방법입니다. 따라서 이 공격 벡터가 빠르게 성장하고 있다는 것은 놀라운 일이 아닙니다. Sonatype 연구에서는 2020년과 2021년을 비교할 때 650% 증가한 것으로 진단했습니다.