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

Automatically open an issue for new CVEs #104

Open
briandfoy opened this issue Nov 30, 2022 · 4 comments
Open

Automatically open an issue for new CVEs #104

briandfoy opened this issue Nov 30, 2022 · 4 comments
Labels
Status: needs help needs outside expertise or capacity Type: enhancement improve a feature that already exists

Comments

@briandfoy
Copy link
Owner

briandfoy commented Nov 30, 2022

I have an RSS feed for new reports in the MITRE search results. It's made by util/make_feed. It's quick and dirty, and a cron job uploads the file to the website.

There are a few things I'd like to do with this, but the first one is to automatically open a new issue when we encounter a new entry. This could be part of util/make_feed, or something could read util/make_feed to do it, or whatever. A GitHub workflow would be nice, but somehow it needs to know how to not submit an issue more than once.

Everything should probably go through the lib/Local/CPANSA module. That would get two new functions: cve_reported and make_cve_issue. Along with the existing cve_recorded and cve_ignored, the module could figure out if the issue should be reported. And, since it controls how it reports, it can tag the issue in some way so let it know it's already been added. Lots of this probably needs the GitHub API.

Even better would be something that also made the PR, even if it's slightly off and requires a little intervention.

@briandfoy briandfoy added Type: enhancement improve a feature that already exists Status: needs help needs outside expertise or capacity labels Nov 30, 2022
@n1vux
Copy link

n1vux commented May 12, 2023

meantime, is the RSS feed working properly?

I suggest not?
It's still reporting CVE-2022-44542 Nov. '22 (updated Dec. '22) as latest; would expect
CVE-2023-31486 HTTP::Tiny 0.082 to be latest on RSS currently. (Which i do see is in github version of lib/CPAN/Audit/DB.pm but not in CPAN release version yet.)

I note CVE.MITRE.org is advertising 2023 feed format changes and ?gradual? migration to cve.org , which might be related to RSS ?

So meantime, if the RSS was working, as a former INFOSEC person still passionate about Perl, i'd consider volunteering to assist with reading the CVE/NVD entrails and updating the manual entries. (Although it seems you are uptodate on CVEs on GH, just not on CPAN.)

@briandfoy
Copy link
Owner Author

The latest on the feed is the latest issue that has not already been added in a report. That is, the feed only includes issues we haven't handled (or ignored) yet. CVE-2023-31486 is already in the file for cpansa/CPANSA-HTTP-Tiny.yml. Sometimes I find out about these before the feed is made, so they never make it into the feed.

If you want to add reports, go for it. The CONTRIBUTING doc should show you most things, and there's usually something to manually adjust.

@n1vux
Copy link

n1vux commented May 13, 2023

Ahh! (Thanks for quick reply!)
From the documentation i was expecting the Nothing New Today "daily" message if there was nothing added recently, not the newest thing neither ignored or used. This makes sense, just is not how i read the make_feed doc.

Since CVE-2022-44542 lesspipe is a Gentoo program that is evaluating untrusted Perl Storable files (CWE-502 Deserialization of Untrusted Data), no CPAN footprint, it could be an Ignore? is it staying on feed for consideration of whether it might be desirable and plausible to detect it anyway, sort of the inverse of the libraries situation? Or a reminder of some other plan to deal with it?

I skimmed both CONTRIBUTING files; I expect it will be a rare day when I get to a new CVE before you do, but I've now got the RSS in my feed-reader and you've assured me it's sensible, so I may notice and try it.
(I also note the Review Existing Data section.)

? I gather one wants to be working in git clones of cpan-audit to have the submodule structure (and not using a perlbrew+cpanm build of CPAN::Audit) in order to consume latest DB from git repo, and a separate git clone of cpan-security-advisory to work on CPANSA itself ?

That's hinted at by make submodules in CPAN::Audit's Contributing.md but isn't explicit.
I fear folks setting up CPAN::Audit in the CI or similar will be pulling from CPAN into their Docker or whatever and the Contributing file wouldn't be the first place they'd look to see how to get the freshest DB.

@briandfoy
Copy link
Owner Author

Let's move this conversation to somewhere else if you have other questions that don't relate to the title of the issue :)

But in short, you don't need to care about CPAN::Audit to work in this repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: needs help needs outside expertise or capacity Type: enhancement improve a feature that already exists
Projects
None yet
Development

No branches or pull requests

2 participants