INTPYTHON-821 Add SBOM update automation

[thanhnguyen-mdb]

INTPYTHON-821

Summary

Added in Github action workflow for SBOM automation. This triggers on changes to any of the requirements and toml files on the master branch. A new branch will be created for the PR and closed on merge.

Sample PR for the SBOM: thanhnguyen-mdb#4

Changes in this PR

New sbom.yml file for the Github action workflow

Testing Plan

Tested through Github Action triggers

Checklist

Checklist for Author

• Did you update the changelog (if necessary)?
• Is the intention of the code captured in relevant tests?
• If there are new TODOs, has a related JIRA ticket been created?

Checklist for Reviewer {@primary_reviewer}

• Does the title of the PR reference a JIRA Ticket?
• Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
• Have you checked for spelling & grammar errors?
• Is all relevant documentation (README or docstring) updated?

[thanhnguyen-mdb]

Need to update this to use cyclonedx-py plugin instead. Will move to ready review once finish.

[aclark4life]

LGTM!

[timgraham]

You write that "This triggers on changes to any of the requirements and toml files on the master branch.", however, it's also obsoleted whenever a new version of pymongo or Django is released that matches the requirements. For example, we have the dependency "django>=5.2,<6.0" and generally a new version of Django 5.2.x is released each month. Does the SBOM need to be updated each time?

[thanhnguyen-mdb]

You write that "This triggers on changes to any of the requirements and toml files on the master branch.", however, it's also obsoleted whenever a new version of pymongo or Django is released that matches the requirements. For example, we have the dependency "django>=5.2,<6.0" and generally a new version of Django 5.2.x is released each month. Does the SBOM need to be updated each time?

The SBOM doesn't become stale when new patch versions are released. The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available. The workflow triggers only when dependency specifications actually change in the requirements files (based on what runtime users would install). When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

It does become stale in release branch if you are making one off requirements change in those branch though if that's what you're referring to? If that's the case then those branch sbom would need to be updated as well.

[timgraham]

The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available.

This doesn't seem true. In thanhnguyen-mdb#4, I see a refernce to "Django==5.2.8" which was the latest Django release at the time that job ran.

When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

You'll have to explain more about how this works. Our release process doesn't use release branches. Currently, the main branch corresponds to Django MongoDB Backend 5.2.x which works with Django 5.2.x. We have for older versions, e.g. the 5.1.x corresponds to Django MongoDB Backend 5.1.x and Django 5.1.x.

[thanhnguyen-mdb]

The SBOM captures the minimum required versions from the dependency ranges in requirements.txt (e.g., Django 5.2 from django>=5.2,<6.0), not whatever latest version happens to be available.

This doesn't seem true. In thanhnguyen-mdb#4, I see a refernce to "Django==5.2.8" which was the latest Django release at the time that job ran.

Sorry, got info a bit mixed up. It's the minimum version/installed version when a user runs pip install -r requirements.txt (runtime version for their python version).

When release branches are cut, it should automatically snapshot the sbom.json from main at that point in time, which ships with that release.

You'll have to explain more about how this works. Our release process doesn't use release branches. Currently, the main branch corresponds to Django MongoDB Backend 5.2.x which works with Django 5.2.x. We have for older versions, e.g. the 5.1.x corresponds to Django MongoDB Backend 5.1.x and Django 5.1.x.

Ah that makes more sense then! If I make it trigger a PR on master/release branch (5.1.x, etc), would that suffice then? This would be a bit more PR but will keep all branch updated. Welcome to suggestions here.

I'll add extra logic to avoid false positive PR in the meantime.

[timgraham]

Here's how I foresee this script working:

1. We bump the main branch to Django 6.0, so SBOM is updated for Django 6.0, the current version of pymongo, and the current versions of the dependencies of these libraries.
2. We likely won't update requirements.txt for the rest of Django 6.0.x, however, in the meantime Django 6.0.1, Django 6.0.2, etc. will be released monthly, some which may contain security fixes. Is it important to have the SBOM include these updates or no?
3. Say we did add some dependency in requirements.txt (or even make some unrelated change in pyproject.toml, say a new version of Python is released and we add the trove classifier in pyproject.toml). That will invoke this job and cause the SBOM to update Django 6.0 and the other packages to their newest versions.

It seems very arbitrary to make these sort of updates based on when changes to these files are made. Do you see my point?

[timgraham]

Ah that makes more sense then! If I make it trigger a PR on master/release branch (5.1.x, etc), would that suffice then? This would be a bit more PR but will keep all branch updated. Welcome to suggestions here.

It doesn't seem correct. An update to the dependencies on the main branch doesn't mean they changed on other branches.

[thanhnguyen-mdb]

@timgraham I've added in the update as discuss yesterday. Will now only do PRs if the sbom content actually changes by using cyclondx-cli tool diff options on components. See here for a test run in my fork:
https://github.com/thanhnguyen-mdb/django-mongodb-backend/actions/runs/19968310880/job/57265977438

I've also tested on a diff branch trigger to make sure PR submits to that branch: thanhnguyen-mdb#9

This PR only has main for now. Please add new release versions to it that you want to track later. Let me know if you need any other changes