Evaluate generation of aboms for ci/cd dependency analysis

[dave2wave]

I saw a note about Generating aboms on the OpenSSF slack. This tool may be a useful analysis gathering step in an atom analysis workflow.

Let's discuss.

[raboof]

While I find the whole 'everyone wants to be a BOM' thing a bit cringey, this might potentially be a neat tool to build #606 on top of.

[dave2wave]

@potiuk For python and npm type actions the verify-action-build script could be enhanced to provide a list of dependencies. These should be saved somewhere so that we can easily scan for exposure to vulnerable components.

[potiuk]

@potiuk For python and npm type actions the verify-action-build script could be enhanced to provide a list of dependencies. These should be saved somewhere so that we can easily scan for exposure to vulnerable components.

I don't think we need that - if anything, we should refuse those deps (and we already do in some cases) where "dependencies" in those actions are not fixed (I think vast majority - if not all of our actions have a "pinned" lock file (package.lock/ uv.lock) that contains all dependencies.

So rather than duplicating those we should reject those actions that do not have such a lock - because they are dangerous - as they can bring something we had no idea (and author of the action had no idea) at the time of release - this is what Astral does (I quoted their article recently) - ans this is what has been long requested from GitHub - they had "immutable" actions idea that they generally abandoned (for public actions). This has also been discussed by my friend - Andrew Nesbitt (from the OSS Corps of Security Enginers - https://nesbitt.io/2025/12/06/github-actions-package-manager.html - and I quite agree - everything in our actions should be "locked/pinned".

[potiuk]

Also to add: the reason why not in verify - is because verify is "gating" tooll. Such a tool for abom storage should work when we merge somethign- not for everything. And it's a great oportunity for others to contribute.

So we could have a separate action/tool for it - maybe someone wouid like to use it as an opportunity to test their claude skills and add it.

I added the customary "good first issue" label - so now the issue is in this nice https://github.com/apache/infrastructure-actions/contribute page.

If we do not give people chance to contribute and try to piggy-back into existing (somewhat) related things and peopel who usually look at them we will never grow community.

[potiuk]

BTW: checking for existing lock files for all possible ecosystems is in #770