CI/CD에 OWASP Dependency Check을 추가하여 OSS 취약성 확인

회사 명
개시하다
응용 프로그램 개발에서는 일반적으로 OSS 라이브러리를 활용하지만 가져오는 OSS에서 취약성을 발견할 때도 있다.
개발 초기 단계에서 취약성이 발견됐다면 대응이 순조로웠겠지만, 발표 단계에서 취약성이 발견됐다면 이에 대응하기 위한 재작업도 크게 벌어질 수 있다.
특히 서비스 개발은 발표 속도가 필요해 그 영향이 심각하다.
히타치솔루션에서는 서비스 개발 기반으로 CI/CD(지속적인 통합/지속적인 수송) 환경 정비를 추진하고 있다.
이 같은 취약성 대책에 기반한 재작업 통제를 최소화하기 위해 취약성을 조기에 측정하고 대책을 조기에 실시함으로써 개발 속도를 높이는 메커니즘을 검토 중이다.
이 가운데 OSS가 공개한 취약성 검사 도구인'OWASP Dependency Check'를 시도했다.이번 소개의 일부분.
OWASP Dependency Check
간단하게 말하면, 응용 프로그램을 스캔하고, 의존하는 프로그램 라이브러리를 조사하며, 그 프로그램 라이브러리에 공개된 취약성 정보가 있는지 검사하는 도구이다.
자세한 설명과 사용방법은 아래의 기사 등 다수가 온라인으로 열람할 수 있기 때문에 본 기사에서 생략한다.
◆ CodeZine: OSS 구성 요소에 포함된 업데이트를 시각적으로 표시하지 않은 OWASP Dependency Check
◆ Qita: OWASP Dependency-Check을 사용한 의존 라이브러리 검색 취약성
이번 시도의 사용법
OWASP Dependency Check은 다양한 언어에 대응하지만, 이번에는 자바만 시도했다.
GitLab 을 사용하여 GitLab CI/CD 를 사용하여 자동 구축/테스트를 수행합니다.
개발 과정에서 취약성을 조기에 발견할 수 있도록 구축 작업 즉시 OWASP Dependency Check에 가입하여 구축 도구가 OSS 라이브러리를 자동으로 획득한 후 취약성 검사를 즉시 수행할 수 있도록 한다.
또 OWASP Dependency Check은 취약성 검사 결과의 보고서를 HTML로 출력하므로 GitLab의 Pages에서 보고서를 열람하는 구조를 구성했다.
처리 프로세스의 이미지는 다음과 같습니다.Vulcheck 작업에서 OWASP Dependency Check을 실행합니다.

또한 Vulcheck 작업의 구체적인 처리 내용(.gitlab-ci.yml의 내용)은 다음과 같다.

Vulnerabilitycheck:
  image: (OWASP Dependency CheckをインストールしたDockerイメージを指定)
  stage: vulcheck
  cache:                     # 脆弱性データベースをキャッシュ(※1)
    key: "$CI_PROJECT_ID"
    paths:
      - ./data
  script:
    - mkdir -p ./data        # 脆弱性データベースを格納するディレクトリ
    - HOMEDIR=$(pwd)
    - ln -s ${HOMEDIR}/data /usr/share/dependency-check/data     # dependency checkの規定のDB保管場所にリンク
    - /usr/share/dependency-check/bin/dependency-check.sh --scan ./ --project $CI_PROJECT_NAME -l log.txt      # スキャン実行。--scanオプションには、ビルド済みのアプリが格納されたディレクトリを指定
    - cp ./dependency-check-report.html ./index.html             # pages用に脆弱性レポートの名前を変更
  artifacts:                 # 次のステージに引き継ぐファイルの指定
    paths:
      - ./index.html         # 脆弱性レポート   
      - ./log.txt            # 実行ログ
    expire_in: 1 day         # 作成物の保存期間(有効期限)を指定

(※ 1) OWASP Dependency Check은 처리 시작 전에 NVD(National Vulnerability Database: 미국 국립표준기술연구소의 취약성 DB)의 취약성 데이터를 다운로드하지만 모든 데이터를 다운로드할 때마다 시간이 걸린다.따라서 먼저 다운로드한 데이터를 캐시하고 다음 이후에는 차분만 다운로드한다.
써봐야 아는 거.
OSS의 취약성 검사를 손으로 조작해 실시할 경우 크게 3단계로 나누어 실시할 계획이다.

어플리케이션 종속 OSS 라이브러리 요약

OSS에 대한 일람화된 취약성 조사

조사에서 발견된 취약성이 응용에 미친 영향

OWASP Dependency Check은 이러한 작업을 자동화합니다. 이번 시도의 결과는 다음과 같습니다.
1. 종속 OSS 라이브러리 목록화
테스트 범위 내에서 OSS에 의존하는 목록을 자동으로 표시할 수 있습니다.
앱의 규모가 커지면 사람 조사는 거의 불가능하기 때문에 나는 이것이 매우 편리하다고 생각한다.
2. 취약성 없는 검사 기능은 제한적
테스트 범위 내에서 취약성 검사 기능의 정밀도는 그다지 좋지 않다.
원인은 다음과 같은 두 가지가 있다.
◆CPE(공용 플랫폼 목록)의 추정 정밀도 낮음
첫머리에 소개한 글도 기재되어 있어서 생략합니다.
◆ NVD의 등록 정보(CVE(공용 취약성 식별자)와 CPE의 연관성 부족
OWASP Dependency Check의 취약성 검사 기능의 규격에 따라 NVD에 CVE와 CPE의 연관성을 제대로 등록한 것이 전제 조건이다.
그러나 최근 몇 년 동안 OSS의 취약성 보고 건수가 해마다 증가해 NVD의 로그인 정보 업데이트가 늦어질 것으로 보인다.
위에서 설명한 바와 같이 현재 OWASP Dependency Check은 최신 취약성을 감지하는 데 적합하지 않습니다.
낡고 취약한 OSS를 감지하는 용도에 사용하는 것이 좋다.
또 취약성 검출 누락이 있어 대추를 통째로 송출할 수 없다는 보고 내용을 개발자 스스로 면밀히 점검해야 한다.
3. 취약성 영향 조사에 유용한 정보를 얻을 수 있다
발견된 취약성에 대해 보고서에는 심각도나 영향을 받은 버전과 같은 해당 NVD 정보가 기재됩니다.
CVE의 세부내용 페이지에 대한 링크도 기재되어 있어 더 자세한 조사가 필요할 때 편리하다.
보고한 견본품은 아래에서 열람할 수 있으니 참고하시오.
https://jeremylong.github.io/DependencyCheck/general/SampleReport.html
또 OWASP Dependency Check은 NVD만을 자바의 취약성 정보로 활용하기 때문에 대상 OSS의 공식 홈페이지, 메일 리스트 등에 게재된 취약성 정보는 보고서에 포함되지 않는다.
이에 대해서는 필요에 따라 사용자 스스로 조사해야 한다.
최후
CI/CD 기반 서비스 개발에서 OSS의 취약성 검사를 자동 구축 과정에 끼워 넣는 것은 생산 효율을 높이는 데 효과적이다.
이번에 시도한 OWASP Dependency Check이 한 방법이지만 실용적인 과제가 있는 것 같습니다.
앞으로도 더 좋은 도구와 수법을 계속 시도해 보겠습니다.
※ OWASP, OWASP Dependency Check은 OWASP 컨소시엄의 등록 상표 또는 상표입니다.
※ 자바는 Oracle Corporation 및 그 자회사, 관계회사의 미국 및 기타 국가의 상표 또는 등록 상표입니다.
※ GitLab은 GitLab.V. 미국 및 기타 국가의 등록 상표 또는 상표입니다.
※ 기타 기재된 회사명, 제품명은 각 회사의 상표 또는 등록상표입니다.