Generate artifacts workflow #272
Conversation
adamrdavid
added
the
development
adamrdavid
force-pushed
the
generate-artifacts-workflow
branch
from
b35fa1e to
cc44bda
Compare
README.md
Outdated
| - [Remediation Advice](mappings/remediation_advice/remediation_advice.json) | ||
|
|
||
| #### Remediation Training | ||
| - [Source Code Warriors](https://github.com/bugcrowd/vulnerability-rating-taxonomy/commit/ff2999c74ac4f10a6346edd2becfc78a730a09ae/checks?check_suite_id=361261433) |
There was a problem hiding this comment.
This is referencing the artifact via the commit hash. Will this link need to be updated for every build ?
There was a problem hiding this comment.
for now yes, but only on a new release. before we get to that I want to build a little meta page that gets generated and committed with the artifact, so the link will be removed from this page.
There was a problem hiding this comment.
updated this to just point to the main tab temporarily and mention that it is a temporary holding place before we make the meta page.
artifacts/scw_artifact.py
Outdated
| @@ -0,0 +1,40 @@ | |||
| import json | |||
| import requests | |||
| import tests.utils | |||
There was a problem hiding this comment.
Now some of these test utils are used to build an artifacts, would it make sense to move them to out from tests ?
There was a problem hiding this comment.
yes! thoughts on a good place to put them?
There was a problem hiding this comment.
maybe a new dir called utils or maybe all code (non json taxonomy/schema stuff) should go under lib
There was a problem hiding this comment.
Unsure of what the convention is with python but utils sounds like a good name.
There was a problem hiding this comment.
updated file locations. I put everything under lib so it doesn't look so messy and segregates the main taxonomy/schema from dev concerns.
adamrdavid
force-pushed
the
generate-artifacts-workflow
branch
from
b965ac1 to
577aa81
Compare
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
should it be PR's as well to test how it it outputs prior to the merge?
There was a problem hiding this comment.
due to the noisy nature of the command making a bunch of requests to check if they 404 we want to limit it as much as possible, but can adjust moving forward.
Essentially the current setup is to generate every time on a merge to master, or direct push to master, and releases. The other PR: #278 would instead make this a check whether or not it is up to date and require updating.
* Test validating document * Test with file existing, but incorrect * Test with correct json * Adjust event filtering for validation workflow Does this make sense? Ideally we don't run this often, but we want to make sure the links are up to date for each release. * Add readme for remediation * Fix link * delete readme specific mapping for now Co-authored-by: Barnett Klane <[email protected]>
3 participants
Issue:
Handles the source code warrior mapping in a more dynamic way and puts it in artifacts. Eventually I think we will want the artifact generation to actually commit to a directory in the repo, but for now they are just in the
actionstab.Previous solution was a static mapping: #264
CVSS v3 Mapping:
CWE Mapping:
Remediation Advice Mapping:
Deprecated Node Mapping (if needed):
Checklist:
CHANGELOG.mdand marked it Added/Changed/RemovedTo come:
At some point we would like to include an
additional_resourcesdirectory where this map will live with some markdown about how to use it. This action will then be updated to confirm that the generated artifact matches the one committed to that directory.