spec out expanded checklist item schema

[g-k]

Discussed previously in https://github.com/mozilla-services/foxsec/pull/1169, but we want to support the user stories:

• As a checklist provider (i.e. SecOps), I want to easily find items relevant to:
  • service types (static, API-only, server, Admin site)
  • implementation languages (for mozilla, python, rust, node.js)
  • sensitivity of the data being handled (PII, aggregates, public, etc.)
  • expected risks (e.g. you might expect state-level actors to attack a TOR download site but probably not an arewe*yet site)
  • suggested implementor (e.g. Dev, Ops, QA)
  • item type or location (e.g. server TLS config, application code, etc.)
• As a checklist user, I want additional information about checklist items (for self-service or to not have to wait for answers from secops) specifically:
  • why is this suggested or required? (provide example bugs (ideally as "close" to the project as possible i.e. Mozilla bugs from that service or language), links to CTFs and references to learn more (OWASP, NVD, CWE, etc.))
  • is this something I should work on? (i.e. who can or should on this addressing this item)
  • how do I accomplish this? (lints, CI, suggested and audited libraries, general coding best practices, TLS or webserver config snippets)
  • how do I test this? (e.g. how to run the zap baseline locally or curl -I example.com to check websec headers) ideally we just provide a script or config for enabling tracking these in metrics

To support this I'm proposing a single directory (since each item can have many tags) items/ containing JSON files (probably as output of other tools or issue template) with an example:

{
  "tags": ["Dev", "VCS"], # array of strings we'll have to curate
  "id": "59966f75-fb3d-4f6c-ae5b-d38b919f3c7f", # UUIDv4
  "name": "trusted code hosting",
  "description": "Application built internally should be hosted in trusted GitHub organizations (mozilla, mozilla-services, mozilla-bteam, mozilla-conduit, mozilla-mobile, taskcluster). Sometimes we build and deploy applications we don't fully control. In those cases, the Dockerfile that builds the application container should be hosted in its own repository in a trusted organization.",
  "test_command": "python -c \"print(${repo_or_dockerfile_org} in 'mozilla,mozilla-services,mozilla-bteam,mozilla-conduit,mozilla-mobile,taskcluster'.split(','))\"",
  "extra_links": [
    "https://github.com/mozilla-services/github-management"
  ]
}

tools would be (in implementation order):

1. a CLI tool (initially this can be a glorified shell script running jq for tag matches)
2. an entirely static site like https://mozilla.github.io/server-side-tls/ssl-config-generator/
3. an API-backed static site like https://starters.servo.org/
4. output as a single or separate bugs (given a BMO API token or GH creds)

[ajvb]

@g-k Just came to this repo's issues page to create a ticket around the idea of adding id's that would allow for easier reference when discussing the checklist items.

As an example. if

Do not use target="_blank" in external links unless you also use rel="noopener noreferrer" (to prevent Reverse Tabnabbing)

was CI.7 (Common Issues, 7), it could allow for comments like:

@ajvb in regards to CI.7, are those commented out links something you plan on adding back? If so, they need the rel="noopener noreferrer" added to them

So if we want UUID id's for these checks, then it may also be nice to have "human id's" or similar.

[g-k]

Also, want different profiles for site security levels / risk profiles.

Links to relevant metrics on STMO.

[g-k]

Goals are:

• we (SecOps/FoxSec) and other contributors can add and update items and tags
• programmatic filtering and output in one or more of the formats mentioned at the end of https://github.com/mozilla-services/websec-check/issues/15#issue-440860082
• easy to deploy and maintain (i.e. if possible avoid a dedicated DB and CloudOps support)

The tool should take a directory or list of item files with:

• an item's metadata in toml, yaml, or json (ordered by preference / easy of writing)
• text (descriptions, additional info, etc.) in markdown

and extract and convert metadata to JSON and generate alternative output formats for text e.g. converts text from markdown to HTML or .rst.

Then output as HTML, issues/bugs, etc.

A static site generator like Jekyll, Hyde, or Hugo might make sense for this.

[g-k]

metadata example: https://jekyllrb.com/docs/front-matter/