Replies: 2 comments 3 replies
-
This needs some triaging. Can you share the command that was used? |
Beta Was this translation helpful? Give feedback.
3 replies
-
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Background
I'm generating an SBOM for a Python project with a requirements.txt file and noticed unexpected results: some packages are attributed to the instrumentation technique, even though they originate from requirements.txt. I haven't applied the --technique flag yet — I inspected the generated SBOM and found that the techniques used are not as expected. This becomes a problem when I do apply the --technique manifest-analysis filter, because relevant packages are then missing.
What I used
Minimal requirements.txt:
fastapi==0.103.1
sd-aiosmtplib==0.0.2
Expected Behavior
Packages like fastapi (direct) and starlette (transitive) should be attributed to manifest-analysis.
Actual Behavior
fastapi is attributed to instrumentation, not manifest-analysis.
starlette is correctly marked as manifest-analysis.
Rationale
I'm aiming to generate an SBOM strictly based on what's declared in requirements.txt and its transitive dependencies. The presence of unrelated packages due to instrumentation introduces noise. (i.e - pipenv, poetry, atom-tools, ...) Since I want to use the --technique manifest-analysis filter, it's critical that direct and transitive dependencies are correctly attributed.
Questions
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions