Checks for Attachments (Post-OSCAL Internalized Structures)

[ohsh6o]

This is the follow-up from #52, unlike that story, this will focus on data that are no longer attachments, but OSCAL internalized structures.

Relevant documentation from FedRAMP to work on the acceptance criteria below, specifically the table.

Guide to OSCAL-based FedRAMP Content
Guide to OSCAL-based FedRAMP System Security Plans

Preconditions

• A working definition, confirmed with the FedRAMP PMO, of "minimally viable validation" for documents that are attachments and not first-class OSCAL objects, documented and included with developer documentation in this repo.

Acceptance Critera

• Confirm existence and perform minimally viable validations for the following attachments

FedRAMP SSP Template Location	Description	OSCAL XML Model Location	Notes
§15 Attachment 3	Digital Identity Worksheet	/system-security-plan/back-matter/resource/prop[@name="type" and . = "TBD"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 4	Privacy Threshold Analysis (PTA) and Privacy Impact Assessment (PIA)	/system-security-plan/back-matter/resource/prop[@name="type" and . = "TBD"]	PIA & PTA PoC do not need to be considered as valid attachments, analysis will be in follow-up story in roles table, referencing this resource and back-matter
§15 Attachment 9	Control Implementation Summary (CIS) Workbook	(dynamically generated)	This is no longer an attachment, see Guide to OSCAL-Formatted SSP Section 7.1
§15 Attachment 10	Federal Information Processing Standard (FIPS) 199 Categorization	/system-security-plan/system-characteristics/system-information/information-type	This is no longer an attachment and will need to be properly determined elsewhere, see SSP XPath location
§15 Attachment 13	FedRAMP Integrated Inventory Workbook	/o:system-security-plan/o:system-implementation/o:inventory-item	This must be part of /o:system-security-plan/o:system-implementation as shown in previous XPath, will break this into another story

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