-
Notifications
You must be signed in to change notification settings - Fork 24
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
feat: Add findings details to console output #15
feat: Add findings details to console output #15
Conversation
Thanks for the contribution! Can you paste some example output? |
|
Is the purpose of this output to be easy to copy/paste the JSON output into another tool? Or to be easy to read in the github actions console output? If the latter, it looks like we should apply a little extra formatting so the format is easier to read. What do you think? |
Definitely agree with @alexjurkiewicz, if a user would like to just read and get an understanding of what is going on rather than just copy & pasting it, then I think applying some formatting would be nice. However, having said that, this is the formatted version of the above: [
{
"name": "CVE-2020-28928",
"uri": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928",
"severity": "LOW",
"attributes": [
{
"key": "package_version",
"value": "1.2.2-r3"
},
{
"key": "package_name",
"value": "musl"
},
{
"key": "CVSS2_VECTOR",
"value": "AV:L/AC:L/Au:N/C:N/I:N/A:P"
},
{
"key": "CVSS2_SCORE",
"value": "2.1"
}
]
}
] And that is the output for 1 CVE only... imagine 10x or 100x the vulnerabilities; could get quite noisy and unwieldy. There is also a second question to be asked, would you want/need to see all the attributes or only some? How much value does this provide? For this reason, I'd recommend grouping it no matter which version we end up with: |
There is another thought of adding a flag for the extra output which would be "off" by default so the current output stays the same? Thoughts? |
I think we can leave the output enabled by default. People will only read the logs when they need this info, so noisy output every run seems fine to me. You have a good point about the verboseness of "dumb prettifying". I think you are right, we need custom formatting logic here. How about:
To me, this seems like a reasonable compromise between readability and code complexity. What do you (both) think? |
Great idea, that seems much simpler and turns 100 CVEs into 100 lines rather than >20x that. Thoughts on grouping, still?
|
@bryankaraffa can you make these changes? 🙏 |
Formatted output in bd1ce75 and here's example now:
|
Thank you! I've made a couple of style updates, @pzi, mind sanity checking? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to ignore the nitpick about the casing, that was just a consistency thing.
However, if there are no findings (either because there are none or the ones that were found are ignored, we would be showing an empty group.
Which actually raises another question, how does the ignore list come into play here? Should we show which ones are ignored or still list them but flag them as ignored?
Good catch. It seems better to only print non-ignored findings. However, the refactoring required for this seems complex, so I'm inclined to ignore this for now, in the interests of getting the PR merged. |
Works for me. Then it's just the variable naming and showing # pseudo code
if findings.length > 0
findings.each => console.log(...)
else
console.log('No findings') |
Use camel case for variables Co-authored-by: Patrik Affentranger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making these changes @bryankaraffa 👍🏼 LGTM and you are right, we can move forward with what's there and hide "empty Findings" group later if required. You ok with this @alexjurkiewicz?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. I really like this improvement! It's simple code and high value output. Thank you for the contribution 🤲
Unfortunately I can't create a new release from mobile, so I'll check this out on Monday. Must also remember to update the readme tag .. |
Tagged as v1.7.0 <3 |
This adds additional output to the console so it's easier to identify what needs to be fixed from GitHub Action logs