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

Add option to list cpe in reports #121

Open
seancorfield opened this issue Aug 30, 2024 · 3 comments
Open

Add option to list cpe in reports #121

seancorfield opened this issue Aug 30, 2024 · 3 comments
Labels
needs analysis Further hammock time is required to figure out the best solution
Milestone

Comments

@seancorfield
Copy link
Contributor

See #101 -- in order to report a false positive, a user needs the cpe, which means clj-watson needs to report that.

I don't know what this would look like in JSON or EDN (or Sarif?) but maybe this only needs to be an option for stdout* output options?

@seancorfield seancorfield added the needs analysis Further hammock time is required to figure out the best solution label Aug 30, 2024
@seancorfield seancorfield added this to the 6.1 milestone Aug 30, 2024
@lread
Copy link
Contributor

lread commented Aug 31, 2024

I'm re-reading http://jeremylong.github.io/DependencyCheck/general/suppression.html, and see that in addition to the CVE (Common Vulnerabilities and Exposures) and CPE (Common Platform Enumeration), suppressions can also be by GAV (Maven Group, Artifact, Version).

And re-reading http://jeremylong.github.io/DependencyCheck/general/thereport.html, I see that CPE Confidence and Evidence Count describe the CPE, which could be considered interesting information.

And if we look at a DependencyCheck sample report http://jeremylong.github.io/DependencyCheck/general/SampleReport.html, I find the CWE (Common Weakness Enumeration) also very interesting.

An idea: Since DependencyCheck can already generate reports with all this information, we could consider optionally (or always) having it generate its detailed reports instead of clj-watson trying to replicate them.

But... since we also experimentally support the github-advisory, maybe generating our own detailed reports is the way we have to go? (I've not looked into what data the github-advisory includes yet, but I expect it is similar since one of its data sources is the NIST CVE database).

@seancorfield
Copy link
Contributor Author

In #55 I show an example of GAV-based suppression, but I got the impression (from somewhere -- don't remember) that it wasn't really the recommended way to go (although it's certainly the easiest and doesn't require knowing the cpe).

@lread
Copy link
Contributor

lread commented Sep 2, 2024

There are many acronyms, and I'm still learning what they mean.

I see that you suppressed by the packageUrl, which seems very similar to the GAV to me. But packageUrl was added to generically describe any dep, and GAV is for maven deps only. So, it seems the GAV is historical and can always instead be expressed as packageUrl.

I don't know the pros and cons of one suppression technique over another, but DependencyCheck's own custom suppressions always includes a packageUrl, usually cpe (but sometimes cve) in its suppressions.

DependencyCheck's issue form for false positives looks like this:

image

Notice that the packageUrl and cpe are mandatory. The cve can also optionally be provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs analysis Further hammock time is required to figure out the best solution
Development

No branches or pull requests

2 participants