Adding questionnaire activity types

[xenph]

I have added the ability to create activity types with checklists. The checklist template is saved on the activity_type model, and then copied to the activity model on creation.

Currently, the template is JSON in the following format;

{
  "questions": {
           "topic 1": [
                      "Question, or checklist check",
                      "Question, or checklist check"
           ],
           "topic 2": [
                      "Question, or checklist check",
                      "Question, or checklist check"
           ]
  },
  "answers": {}
}

Which will create the following look on the activity detail view.

Answers are saved using the save button.

[xenph]

This is pretty rough, but it doesn't change existing functionality, and every path I tried functioned correctly.

Future changes will evolve the types of answers beyond yes/no, and build a template creation UI, so that you aren't forced to use the JSON.

The questions in my screenshot were taken from GoSDL, which uses the same format, except I have added a answers field to capture the answer.

[xenph]

I'm also hoping to fold the ASVS checks into this so that the checklist can have an "output" which can be surfaced in the UI.

[aparsons]

Hey @xenph, I really like this idea but don't have a valid SDL doc to use as a template. Is there a formal specification for these? What JSON docs have you been using? In my limited research, I found https://github.com/slackhq/goSDL/tree/master/www/sdl/modules. At first glance, it seems like the format differs a bit between the documents.

[aparsons]

Notes for myself:

• Include documentation about goSDL in Manage > Activity Types > Edit View
• Update sample_data.json to not error when loaddata sample_data.json (may have been broken for a while)
• Validate the questionnaire results are visible on the activity page
• Review Javascript
• Consider a specialized filter for rendering these SDL documents like the markdown_render.py. This would allow the SDL documents to be shown without relying on Javascript.

[xenph]

I used: https://github.com/slackhq/goSDL/blob/master/www/sdl/modules/general.json for testing, with the small addition of a "answer" field, here is exactly what I used:

{
  "title": "General Guidance",
  "description": "Applies to All Projects: Standard security guidance that all projects, regardless of features, need to follow.",
  "tags" : "WebApp, API, MessageServer, iOS, Android, Electron, WindowsPhone",
  "minimum_risk_required" : "Low Risk",
  "answers": {},
  "questions": {
    "General": [
      "We have completed a high-level [STRIDE](https://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx) threat model of your project or feature.  For any potential issues that arise from following this process, please comment and detail them on this jira card.",
      "We have tagged any bugs filed as a result of items in these checklists with '`security`' label.",
      "Our application is running on machines supported by Operations.",
      "We have thought about the default settings of this feature to ensure they are as secure and de-permissioned as possible.",
      "We have looked at past bug bounty issues (tagged with '`bugbounty`') specific to this feature, functionality, or other similar features and ensured we're not making similar mistakes.",
      "We have checked for dead code, and deleted it. Less code = fewer bugs!",
      "We have not implemented any user-impersonation functionality.  If we have, we have had an in-depth discussion with the product security team about it",
      "When a user is disabled or deleted, our functionality is not affected at all and we have no additional tasks to perform.  (For instance, when a user is created, and if they interact with our component, we don't need to perform any cleanup on behalf of a user delete or disable)"
      ],
    "Privacy": [
      "We only utilize third-party services supported by IT or Operations",
      "We have ensured that error messages don't leak sensitive information (debug/callstack/full objects) to a user"
      ]
  }
}

Of this object, I only look at the questions and answers field right now, the plan would be to grow to include other features, such as question types, and gaining a result from the answers (risk, pass/fail, or similar)

[aparsons]

@xenph I did some prototyping for a gosdl class representing the modules. I was thinking this could be the basis of a custom renderer so javascript wouldn't be needed to display and update the values. I was trying to go off the spec as defined in that repository. What are your thoughts on this approach?

Am I correct that this specification is custom to the security team at slackhq? Is anyone else using it?
This could also be an independent python library if you like this approach.

[xenph]

I think this approach is much better than my very lazy informal approach.

Yes, the schema is specific to the slack SDL tool, I don't know of anyone else using it. I think building an independent library is the right approach, as the schema supports a lot more than I was using it for originally.