Open robbieaverill opened 6 years ago
If we use silverstripe.org to power this we will probably need to add more structured data fields, since the "versions affected" field doesn't distinguish repositories well (for example)
Just thought about this again. This is what we have in the SilverStripe.org CMS at the moment:
We could probably replace this with two textareas and use a structure like one line per module, and the format of [composer module name]: [semver constraint]
for each line. This would be structured enough and would require minimal changes to the website (replace new lines with comma delimited). Edit: actually we can probably leave this as it is and just ensure we have consistent structure in the composer module name and semver constraint. Would require a little retrospective editing of ss.org advisories to ensure they all conform.
We could potentially also add an API endpoint to expose the structured data for all security announcements on the website as structured JSON, and then this command could essentially run a sync command to pull the security advisory repository, rebuild all security alerts and make a commit if anything new is added.
@chillu do you have any thoughts on this? I'll probably pick it up on hackday.
FYI there's a PoC branch here:
https://github.com/creative-commoners/cow/tree/pulls/master/add-advisory-sync
Also, a team is overhauling SS.org right now - I'm trying to get some more defined form fields for adding security advisories in the CMS.
😄
A multi-input list of composer package names and semver constraint fields would be ideal, e.g.:
Affected package | Constraint | Fix version(s) |
---|---|---|
silverstripe/framework | ^4.0.2 | 4.0.9, 4.1.1, 4.4.3 |
silverstripe/admin | ^4.0 <4.3 | 4.0.2, 4.1.1, 4.2.9 |
Just an idea...
I think we should base this on Github's new security advisories, rather than FriendsOfPHP. Which submits CVEs as well. Between those two, we cover more ground than through FriendsOfPHP + CVE? See https://github.com/silverstripe/silverstripe-framework/issues/9335
It'd be nice if GitHub exposes the ability to do this via their API at some point!
Here's an example of the confusion caused by not being clear about the module that a release relates to :)
A multi-input list of composer package names and semver constraint fields would be ideal, e.g.:
You could also argue that if a vuln is present in more than one module, it should be flagged as multiple vulns. That makes it less ambiguous if you're still running vulnerable code as well. https://github.com/FriendsOfPHP/security-advisories/ doesn't seem to allow referencing multiple packages in a single issue, so we shouldn't either.
I'd argue that there's two levels of information:
Proposed ACs:
The SensioLabs security checker (and the PHP package for it) uses https://github.com/FriendsOfPHP/security-advisories as a data source, which contains some of our older vulnerabilities that were manually added.
It would be nice for cow to automate this process to some extent, so we can incorporate pushing out security notifications to repositories like this one. This would add weight to some of the features of CWP coming up like the "site summariser" module which includes listing known security vulnerabilities in the report: https://github.com/bringyourownideas/silverstripe-composer-security-checker and https://github.com/bringyourownideas/silverstripe-maintenance/
Some implementation ideas:
Other considerations:
Contributing guide: https://github.com/FriendsOfPHP/security-advisories#contributing
First priority would be to ensure that this repository is up to date with the current list of disclosed vulnerabilities (cc @stevie-mayhew)