Generative Example SSP Data

[ohsh6o]

Extended Description

As a tool developer, to better understand the range of validation conditions messaging and grouping, I would like to have access to a tool to generate ad hoc system security plans for testing, with or without defects.

Preconditions

• UX Spike to assess the efficacy of include SSP generator tooling into the prototype UI (18F/fedramp-automation/#143)

Acceptance Critera

• [ ] A XSLT transform that, with parameters to toggle the options on and off, that can randomly generate on the fly:
  • [ ] A complete or incomplete/invalid set of control implementation implemented requirements, and a parameter to generate x/y control implementations that are in some way invalid for y required in a baseline.
  • [ ] Valid or invalid control originations with a parameter to set x/y control originations as invalid.
  • [ ] A complete or incomplete/valid user role table that is or is not properly mapped into responsible role for an implemented requirement in a control.
  • [ ] A valid and invalid MVP inventory.
  • [ ] A valid set or underdefined set of required attachments.
• Depending on the precondition, potentially integrate the ability to operate it from the UI

Story Tasks

• [ ] Tasks...

Definition of Done

• [ ] Acceptance criteria met - Each user story should meet the acceptance criteria in the description
• [ ] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove
• [ ] Code quality checks passed - Enable html tidy with XML code standards as part of the build (from QASP)
• [ ] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing
• [ ] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
• [ ] Source code merged - Code that’s demoed must be in source control and merged
• [ ] Code must successfully build and deploy into staging environment (from QASP): this may evolve from xslt sh pipline into something more
• [ ] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling?
• [ ] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP)
• [ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team)
• [ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)
• [ ] Code refactored for clarity - Code must be clean, self-documenting
• [ ] No local design debt
• [ ] Load/performance tests passed - test data needed - saxon instrumentation
• [ ] Documentation generated - update readme or contributing markdown as necessary.
• [ ] Architectural Decision Record completed as necessary for significant design choices

[ohsh6o]

Will need to review this in the next week or so for operational complexity and policy requirements in FedRAMP/GSA re classification and marking of this data.

[ohsh6o]

Superseded by 18F#290. Will close this and move to done column.