Hold meeting to determine how/if to streamline and improve log review process

[jason-upchurch]

Problem
Because of inconsistent conclusions between snyk cli and web interface (see related issue research inconsistency between snyk cli and web interface #3760), it would be helpful to use cli interface to perform dependency vulnerabilities on remote server.
Modified in Sprint planning to hold meeting.

For reference: https://github.com/fecgov/FEC/wiki/Security-Event-Review-Checklist

Recommended steps

• Meet to discover an accepted strategy
• Create follow up ticket

[jason-upchurch]

If this works, we would want to try it out with other repos

[lbeaufort]

@jason-upchurch another possibility might be to use GitHub vulnerability tracking. We would want to make sure it doesn't also have false-positive issues. https://help.github.com/en/articles/about-security-alerts-for-vulnerable-dependencies

[jason-upchurch]

@lbeaufort it's probably good to complement snyk with other tools until any one is well understood. I think snyk has good language coverage, but I don't have a full understanding of the options. In addition to CLI/Web interface inconsistency, we should probably expect inconsistencies between any two tools as well (not necessarily a bad thing).

The false positive issue is just something for log reviewers to keep in mind when making reports, as I imagine any tool has to make a tradeoff between false positives and missed detections. As a reviewer, a downstream goal may to write a simple shell script that targets the same files as the web interface.

[jason-upchurch]

GitHub tracks public vulnerabilities in packages from supported languages on MITRE's Common Vulnerabilities and Exposures (CVE) List. We also scan data in public commits on GitHub and use a combination of machine learning and human review to detect vulnerabilities that are not published in the CVE list.

With the ML and human review this may be a great complement! Following is a snippet from snyk

Monitoring other vulnerability databases, such as CVEs from NVD and many others.
Monitoring user activity on GitHub, including issues, PRs and commit messages that may indicate a vulnerability.
Bulk research, using tools that look for repeated security mistakes across open source package code
Manual research, investing our researchers time to manually audit more widely used packages for security flaws.

It's probably good to have more coverage, and it looks like the GitHub monitoring registration is super easy:
https://help.github.com/en/articles/managing-alerts-for-vulnerable-dependencies-in-your-organizations-repositories

[jason-upchurch]

Additional resource for static analysis discussion: before-you-ship.18f.gov.

[jason-upchurch]

closing issue in favor of additional tool training #3920