こんにちは。プラットフォームGのPlatformEngneeringチームでPlatformEngineeringの考え方をベースにツール周りの開発・運用・展開の役割(とチームリーダーのようなことをしている、最近はスクラッチ開発側も担当するようになったんでスクラムとかプログラミング言語周りにひーひー言っている)島村です。

この記事は KINTOテクノロジーズアドベントカレンダー2024 の4日目の記事です🎅🎄

背景

SBOM(Software Bill of Materials)というものがあります。

2024年に経済産業省がセキュリティ対策に役立てましょうというのも言ってますし、2021年にアメリカでは標準で作ろうというお話にもなっております。とはいえ、そのために新しいSaaSとかOSSとか色々と導入するのはハードルが高い！と考えてしまうかもしれません。

KTCでは、OSSを活用してCICDのパイプラインに組み込んで、標準的にSBOMを作成して管理しています。
DevSecOpsの文脈で、SBOM作成に合わせて

• 脆弱性スキャン
• EOLの検査

も行っています。
「ミニマムスタート」と、その改善の事例としてご紹介します。

利点と欠点

何を使ってたっけ？が見えることが一番！

ちょっと前だと、log4jの脆弱性対応が記憶にあるとおもいます。弊社でも使ってないよね？という調査依頼が出されました。当時は設定ファイル見たりとか暫定の回避設定を共通で入れるように周知しましたが、今なら検索すれば一発でわかります。

• 利点
  • 無料 でEOL/SBOM管理が始められる！👌
    • 有償だとYamory(Cloudサービス)とかBlackDuckがあります
    • SBOM生成だとMicrosoftが提供しているSBOM-TOOLもあります
    • 有償ソフトウェアとかSaaSは申請とか諸々の手間が…
  • 使っているツール群はGitHubActionsのActionとして準備されているので、使いやすい。
  • ローカルでも動かせるので、色々とユースケースとして考えることができそう
• 欠点
  • endoflifeなど有志に支えられているものが多いです
  • xeol/syftともに開発が進んで頻繁にバージョンアップされていて、ファイルの不整合が起きることがたまに

ツール一覧

ワークフロー概要図

パイプライン抜粋(GitHubActions)

基本的にはアプリケーションビルドではなくShipのタイミングで実施しましょう。

SBOMファイルはバージョン管理をしてもよかったんですが、最新のみで問題はないかなと考えて、上書きするようにしています。ビルドに組み込むと、実際にワークロードにあるコンテナのSBOMじゃないものになるので、注意が必要です。

パイプラインでXEOLを2回呼び出しているのは、GitHubActionへのログ表示とファイル生成のためです。モードが別のようで、一括でやってくれなかったんで、分離することになりました。

    ## Trivyでの脆弱性診断
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: '${{ ImageName }}:${{ IMAGETAG }}'
        format: 'table'
        exit-code: '0'  ## 脆弱性があってもImageBuild/Pushをする場合はここを「0」にする
        ignore-unfixed: false
        vuln-type: 'os' ## Javaなども含みたい場合は「library」を追加する
        severity: 'CRITICAL,HIGH'

    ## SYFTでのSBOM作成
    - name: Run Syft make sbom files(format cyclone-dx)
      uses: anchore/sbom-action@v0
      with:
        image: '${{ ImageName }}:${{ IMAGETAG }}'
        format: cyclonedx
        artifact-name: "${{ github.event.repository.name }}-sbom.cyclonedx.xml"
        output-file: "${{ github.event.repository.name }}-sbom.cyclonedx.xml"
        upload-artifact-retention: 5 ## Artifactの有効期限

    ## XEOLでのSBOMからのEOLライブラリ検知(WF中での表示)とファイル作成
    - name: Run XEOL mw/sw EOL scanner from sbom file
      uses: noqcks/xeol-action@v1.1.1
      with:
        sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml"
        output-format: table
        fail-build: false

    - name: Run XEOL mw/sw EOL scanner from sbom file and Output file
      uses: noqcks/xeol-action@v1.1.1
      id: xeol
      with:
        sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml"
        output-format: json
        fail-build: false

    ## AWSのクレデンシャルの設定(SBOM)
    - name: AWSクレデンシャル
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: ${{ S3_ACCOUNT_ROLE }} 
        aws-region: ${{ AWS_REGION }} 

    ## SBOM/EOLを管理するTeamのS3Bucketに保存する
    ## イメージ名やリポジトリ名でS3の中で階層分けをするので、Cutで抽出。
    - name: SBOM and EOL file sync to s3 bucket
      run: |
        ECRREPOS=`echo ${{ ImageName }} | cut -d "/" -f 2,3`
        echo $ECRREPOS
        aws s3 cp ${{ github.event.repository.name }}-sbom.cyclonedx.xml s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/sbom-cyclonedx.xml
        aws s3 cp ${{ steps.xeol.outputs.report }} s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/eol-result.json

改善されたことと今後

自分の部署で、AWS-COREのライブラリを使っているかどうかを確認した結果

自分の部署で、EOLがあるかどうかを確認した結果

KTCではCMDBへSBOM/EOLの一覧を取り込んだため、

• 自身のプロダクトに何のライブラリが使われているか？
• EOLになっているものはないか？

が上記の通り、検索して確認できるようになりました。内製CMDBでは直近でEOLになるライブラリ・パッケージも出してくれるので、事前対応も容易です。

SBOM管理の第一歩は、SBOMファイルなどをJSONで出力して、jqで成形してエクセル管理でもいいと思います。

今後は、定期的にEOLを含んだプロダクトへ、チケットで対応依頼を行う運用を開始したいと考えています。
セキュリティチームとか色々と巻き込んでいくつもりです。

所感

EOL管理周りのツールは調べましたが多くはなく、SBOM管理とかソフトウェア管理、資産管理の延長として提供しているものが多い印象です。
OSSやライブラリを使った開発も多いので、EOLを定期的に見れる改善は脆弱性対策としてもかなり有用かと感じています。ライブラリも1年～2年でEOLとなって、バージョンの追従をする必要が多いと思いますし。

見えるというのは、"気付かない"・"見なかったことに"という対策には良いと思いますので、O11yと同じでまずは「みえる」を目標にしましょう。

実際には、修正依頼も含めた運用まで建付けないと、実効性はないのかもしれません。
が、「ミニマルから始める」と題して、まずは作ろう！始めよう！ということで、今回の記事を書きました。

さいごに

PlatformEngneeringチームは、社内向けの横断ツールを統制して必要なものを開発しています。
Platformグループの他チームが作ったものを受け入れたり、必要なものを新規作成や既存のものをマイグレーションしたりしています。MSPチームの定例作業の自動化とか、CDKにも手を出そうとしてるので、ManagedService以外にもプログラミングも行い始めました。
こういった活動に少しでも興味を持ったり話を聞いてみたいと思った方は、お気軽にご連絡いただければと思います。