코드에 무엇이 숨겨져 있나요?

간단한 프로젝트라도 빠르게 확장되는 방법이 있으며 기존 코드 또는 노드 라이브러리를 쉽게 통합할 수 있어 이러한 경향이 증폭됩니다.

혼자 코드를 작성하는 경우에는 여전히 어느 정도 관리하기 쉽지만, 일반적인 경우처럼 여러 개발자와 팀이 코드를 작성하면 더 어려워집니다.

모든 풀 리퀘스트 승인을 담당하는 팀장이라도 모든 코드 라인, 모든 기능, 모든 변수를 알 수는 없습니다.

신뢰의 문제

이것이 2020년 후반에 Orion 앱에서 사소한 코드 변경이 발생한 이유 중 하나입니다. 태양풍, 너무 오랫동안 감지되지 않았습니다. 전체 변경 사항은 단지 수십 줄의 코드였으며 매우 훌륭했습니다. 원래 클래스 안에 숨겨져 있음.

변경된 제품은 서명이 제대로 되어 있어서 의심할 이유가 없었고, 개발팀은 코드 소유자를 신뢰했습니다.

최근에야 우리는 NPM에 “논리적 결함”를 통해 악의적인 행위자가 악성 라이브러리를 합법적인 라이브러리로 가장할 수 있게 되었습니다. 기본적으로 NPM은 사용자에게 알리거나 동의를 얻지 않고도 누구든 패키지 관리자로 추가할 수 있도록 허용했습니다. 

이를 통해 악성코드가 포함된 패키지를 생성하고 이를 신뢰할 수 있고 인기 있는 유지관리자에게 자신도 모르게 할당할 수 있었습니다. 잘못된 신뢰의 경우 코드에 문제가 있는 취약점이 숨겨져 있음을 의미할 수 있습니다.

고려해야 할 또 다른 일반적인 방법은 개발자가 자신의 코드에 사용하거나 새 라이브러리에 다시 업로드하기 위해 기존 라이브러리 또는 StackOverFlow에서 코드를 복사하여 붙여넣는 것입니다. 그렇게 하면 현재 본질적으로 추적되지 않는 안전하지 않고 취약한 코드를 복사할 가능성도 높아집니다. 원본 코드가 CVE를 받고 최종적으로 수정되더라도 복사한 문제가 있는 기능은 보이지 않으며 앞으로 몇 년 동안 이를 사용하는 모든 코드베이스를 오염시킬 수 있습니다. 

최근 캔자스 대학교에서 실시한 연구에서(“포크는 무엇입니까? npm에서 숨겨진 코드 클론 찾기”), 연구원들은 완전히 검증된 패키지를 사용하는 것조차 안전하지 않을 수 있음을 보여줍니다.

그것에 대해 무엇을 할 수 있습니까?

따라서 공급업체의 서명된 제품과 업데이트를 신뢰할 수 없습니다. 모든 외부 라이브러리와 코드가 통합되어 있기 때문에 여러분의 코드가 이미 수정되거나 추가되었을 수도 있습니다. 그렇다면 시스템에 악성 파일이 설치되지 않는다는 것을 정말로 확신하기 위해 무엇을 할 수 있습니까?

다음과 같은 몇 가지 작업을 수행 할 수 있습니다.

1. 통합한 각 라이브러리 소유자 또는 프로그램 공급업체로부터 완전한 SBOM을 요청하십시오. SBOM은 라이브러리나 제품의 모든 '성분'이 무엇인지 확인하는 데 도움이 될 수 있습니다. 또한 SBOM에 나열되지 않은 항목을 라이브러리나 제품에서 발견하면 의심스러운 것으로 간주해야 합니다. SBOM이 무엇인지 자세히 알아볼 수 있습니다. 여기에서 지금 확인해 보세요..
2. 무결성 검사가 이루어졌으며 기대한 결과를 얻고 있다는 신뢰할 수 있는 증명을 공급업체나 라이브러리 소유자에게 요청하세요. 공급업체 자체의 보증만 신뢰할 필요는 없습니다.
   
3. 패키지를 설치할 때 npm CLI 플래그를 사용하십시오. --ignore-scripts 설치 단계에서 타사 패키지의 스크립트가 실행되는 것을 방지합니다.
4. 사용하십시오 패키지 잠금.json 패키지 버전 번호를 잠그는 파일입니다. 당신이 사용할 때 패키지 잠금.json 사용 중인 패키지 버전을 잠글 뿐만 아니라 해당 패키지 버전의 종속성도 잠그는 것입니다. 다양한 버그에 대한 수정 사항이 포함될 수 있는 자동화된 패키지 업데이트를 가져오지 않을 위험이 있습니다. 그러나 특정 버전을 확인하기 위한 작업을 수행했고 이를 먼저 확인하지 않고 다른 것을 포함하고 싶지 않은 경우 버전 번호를 잠그는 것이 최선의 선택입니다.

수행원 새로운 규정, 대부분의 사람들은 가까운 시일 내에 SBOM을 사용하기 시작할 것으로 예상됩니다. 더 많은 회사가 SBOM 및 기타 증명을 요구할수록 더 많은 조직과 유지관리자가 이를 준수해야 합니다.