Skip to content
This repository has been archived by the owner on Oct 9, 2020. It is now read-only.

expand and clarify the security section #19

Open
greggles opened this issue Apr 1, 2020 · 4 comments
Open

expand and clarify the security section #19

greggles opened this issue Apr 1, 2020 · 4 comments

Comments

@greggles
Copy link

greggles commented Apr 1, 2020

The security section currently reads:

Clean tests from a static testing SaaS (such as npm audit) and from OWASP ZAP, along with documentation explaining any false positives

The npm audit tool is a very necessary security check and it does kind of seem like static testing. However npm audit does not seem like a sufficient tool static testing tool. Similarly, ZAP is great but I believe it requires a skilled individual using it to be effective. I think there are maybe 3 levels of tools to consider:

  1. Basic dependency checker (e.g. npm audit, roave/security-advisories, snyk)
  2. SAST e.g. the tools on OWASP page Tools
  3. DAST e.g. OWASP Page list

I'd be happy to try to put together a PR if you agree.

@afeld
Copy link

afeld commented Apr 2, 2020

There's a page about it in Before You Ship, if it helps.

@greggles
Copy link
Author

greggles commented Apr 2, 2020

That seems like a great resource. Maybe the section should actually be shortened and link to that.

Combination of manual review and automated testing. See [18f guide to security](https://before-you-ship.18f.gov/security/)

@waldoj
Copy link
Contributor

waldoj commented Apr 2, 2020

@greggles, the security section is one entry in a sample contract artifact — the Quality Assurance Surveillance Plan — to actually be incorporated into an RFP. We cannot advise people to include the "Before You Ship" website into an RFP. The security component of the QASP is not intended to serve as a comprehensive security guide (we'd probably advise NIST 800-53 for that), but is simply an example of the sort of requirements that might be included within the security requirements within the QASP.

@greggles
Copy link
Author

greggles commented Apr 2, 2020

That's some great context, thanks.

I came to this document because it's in a potential set of recommendations to an organization. I read this section and felt concerned that the people receiving it as a recommendation would look at those 2 very specific tools, adopt them, and think they were done. Maybe that's a misplaced concern.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants