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

advisory categories #7

Open
garu opened this issue Oct 19, 2023 · 2 comments
Open

advisory categories #7

garu opened this issue Oct 19, 2023 · 2 comments

Comments

@garu
Copy link
Collaborator

garu commented Oct 19, 2023

Some package managers like Rust's provide a category to their issues' metadata. I think it really helps keep things organized. A given advisory could have multiple categories, even though I believe most will fall under just one.

I'd like us to decide which advisory categories to use, if any. RustSec defines the following categories on their advisories:

  1. code-execution - issue lets attackers run arbitrary code;
  2. crypto-failure - issue related to cryptography and ciphers (man in the middle, recover plaintext, break cipher, etc);
  3. denial-of-service - issue lets attackers hang the program or the entire system;
  4. file-disclosure - issue lets attackers read the contents of an arbitrary file or directory;
  5. format-injection - wrong evaluation of input;
  6. memory-corruption - null pointers, OOB writes, use-after-free, etc;
  7. memory-exposure - issue lets attackers read memory contents;
  8. privilege-escalation - issue lets attackers bypass user permissions;
  9. thread-safety - code is not thread-safe;

For CPANSEC I would also like to consider:

  1. malware - the distribution is or contains explicit malicious code;
  2. memory-leak - circular references and general memory leaks;
  3. unmaintained - distribution is abandoned;
  4. deprecated - author recommends distribution should not be used;

What do you think?

I plan on reviewing all relevant CVEs and adding at least one category for each of them. At the end, we should have a good enough list (we can always add more later).

@stigtsp
Copy link
Collaborator

stigtsp commented Oct 26, 2023

Some thoughs:

  • Should we consider if this fits in with CWE definitions? (https://cwe.mitre.org/)
  • We would need something like "outdated/vulnerable 3rd party component" (like in the case of IO::Compress::Brotli)

@garu
Copy link
Collaborator Author

garu commented Oct 26, 2023

good point, @stigtsp. At first I considered escalating the type of vulnerability from the third party, but "depends on vulnerable third-party component" without specifying the actual issue may be better as it points out the 3rd party library may expose users to other risks outside their perl code - not to mention it makes things much easier for reporters.

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

No branches or pull requests

2 participants