Hello. I'm Shimamura from the Platform Group's Platform Engineering team. I'm responsible for the development, operation, and deployment of tools (taking on roles similar to a team leader. Recently, I've also started working on scratch development as well, which has me struggling a bit with things like Scrum and programming languages) based on platform engineering principles.

This article is the entry for day 4 in the KINTO Technologies Advent Calendar 2024 🎅🎄

Background

There is a thing called SBOM (Software Bill of Materials).

In 2024, the Ministry of Economy, Trade and Industry emphasized the importance of utilizing this for security measures. Similarly, back in 2021, the United States also discussed making it a standard practice. However, introducing new SaaS, OSS, and other tools for this purpose might seem like a significant hurdle.

KINTO Technologies leverages OSS and incorporates it into the CI/CD pipeline to create and manage a standardized SBOM. In the context of DevSecOps, we also perform

• vulnerability scanning
• EOL inspection

in conjunction with SBOM generation. I'll introduce "Minimal Start" and provide examples of improvements made along the way.

Pros and Cons

The most important thing is having visibility into what is being used.

Some time ago, you may remember the vulnerability of log4j. There was an inquiry asking, "We don't use it, do we?" At that time, we communicated the issue by checking configuration files or applying common temporary workaround settings, but now you can find out in a single search.

• Pros
  • EOL/SBOM management can be started for free! 👌
    • There are paid services such as Yamory(Cloud Service) and BlackDuck.
    • There is also SBOM-TOOL provided by Microsoft for SBOM generation.
    • Paid software or SaaS services come with application processes and other hassles.
  • The tools we use are available as GitHub Actions, making them easy to use.
  • It can be run locally, so there are many potential use cases to explore.
• Cons
  • Many of the tools, like EOL and others, are supported by volunteers.
  • Tools like xeol and syft are frequently updated, and sometimes file inconsistencies occur due to version changes.

Tool List

Workflow Diagram

Excerpt Pipeline (GitHub Actions)

Basically, This task should be executed during the Deployment Phase rather than during the Application Build Phase.

While version management for SBOM files was an option, we chose to overwrite them, as the latest version is deemed sufficient. Note that incorporating into the Build will result in an SBOM that does not reflect the container actually present in the workload.

The reason the pipeline calls XEOL twice is to display logs to GitHub Action and for file generation. Since the modes appear to be different, a single unified operation wasn't possible, we decided to separate them.

    ## Vulnerability scanning with Trivy
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: '${{ ImageName }}:${{ IMAGETAG }}'
        format: 'table'
        exit-code: '0'  ## If you want to proceed with ImageBuild/Push despite vulnerabilities, set this to "0"
        ignore-unfixed: false
        vuln-type: 'os' ## If you want to include Java, etc., add "library"
        severity: 'CRITICAL,HIGH'

    ## SBOM generation with SYFT
    - 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 expiration date

    ## EOL library detection (display in WF) and file creation from SBOM in XEOL
    - 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 credential settings (SBOM)
    - name: AWS credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: ${{ S3_ACCOUNT_ROLE }} 
        aws-region: ${{ AWS_REGION }} 

    ## Save SBOM/EOL in the Team's S3Bucket to be managed
    ## Extracted with Cut, as it is hierarchical in S3 by image name or repository name.
    - 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

Improvements Made and Future

The results of checking whether my department is using the AWS-CORE library.

The results of checking whether my department has EOL components.

Since KINTO Technologies has integrated SBOM/EOL lists into the CMDB, allowing us to search and confirm the following:

• What libraries are being used in my product?
• Are there any components that have reached EOL?

With the in-house CMDB, libraries and packages approaching EOL are also highlighted, making it easy to respond in advance.

The first step of SBOM management is to output SBOM files in JSON, formatting them with jq, and manage them in Excel.

In the future, we would like to start the operation of periodically requesting responses by ticket to products that include EOL. This will involve collaboration with the security team and many others.

Impressions

I looked into tools for EOL management, but there aren't many dedicated ones; most seem to be extensions of SBOM management, software management, or asset management. Given the prevalence of development involving OSS and libraries, regularly monitoring EOL can be highly effective as part of vulnerability countermeasures. Libraries often reach EOL within 1 to 2 years, requiring frequent updates to keep up with version changes.

Being able to see the current state is a strong countermeasure against "not noticing" or "ignoring" issues. Similar to observability (O11y), the first goal should be to "make it visible."

In fact, it may not be effective unless it is built up to the operational step which includes requests for fixes. However, I wrote this article under the title "Starting with Minimal" to say, "Let's build it first! Let's get started!"

Conclusion

The Platform Engineering team manages and develops tools used internally across the organization. We leverage tools and solutions created by other teams within the Platform Group. Based on the company's requirements, we either develop new tools from scratch or migrate existing components as needed. We are automating routine tasks for the MSP team and are also starting to explore CDK, so we started programming in addition to Managed Service. If you’re interested in these activities or would like to learn more, please don’t hesitate to reach out to us.