Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark config files as type=file instead of type=application #140

Open
arianvp opened this issue Dec 19, 2024 · 4 comments · May be fixed by #141
Open

Mark config files as type=file instead of type=application #140

arianvp opened this issue Dec 19, 2024 · 4 comments · May be fixed by #141

Comments

@arianvp
Copy link

arianvp commented Dec 19, 2024

It would be nice if config files that end up in the SBOM. (e.g. the derivation for etc and systemd units) are not marked as type=application but only packages are marked as type=application. That makes filtering in SBOM scanners a lot easier

@henrirosten
Copy link
Collaborator

First, notice the default component type was changed ot library in PR: #128.

I agree we should properly classify component types. However, I don't see anything in nix derivation properties that would allow reliably identifying different types.

Any suggestions on how to do this reliably are certainly welcome.

@arianvp
Copy link
Author

arianvp commented Dec 21, 2024

I think one strong indicator for library instead of file is the presence of pname+version instead of name in the nix derivation. We could adjust the metadata scraper to collect this info and use it as a shorthand.

@arianvp
Copy link
Author

arianvp commented Dec 21, 2024

We also opened and RFC to start adding CPE info to packages which might help. NixOS/nixpkgs#354012

@henrirosten henrirosten linked a pull request Dec 22, 2024 that will close this issue
@henrirosten
Copy link
Collaborator

I think one strong indicator for library instead of file is the presence of pname+version instead of name in the nix derivation. We could adjust the metadata scraper to collect this info and use it as a shorthand.

Your suggestion seems to work pretty well: see #141. It needs some more testing still, feel free to try it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants