...
The output from all four scans is provided in two forms: On a weekly basis Stack Armor sends a report (an emailed .zip file). The findings are also provided as issues in a GitLab project. While the emailed report is useful for review by the ISO and sharing with our sponsor, the GitLab issues are more useful for the engineering team, as they can be folded into the team’s work backlog and tracked through to completion. IT meets with StackArmor weekly to discuss the scanning activity and output. The minutes from our (weekly) discussions are kept here. Sage uses automation from Unito.io to mirror the GitLab issues into Jira, as a one-way sync'. At the time of this writing the The issues can be seen in the StackArmor GitLab (SAGL) Jira project. The long term plan is to mirror the issues into the PLFM Jira project but, at the time of this writing, the GitLab issue list has not sufficiently stabilized. As we iterate with StackArmor to obtain a clear issue backlog, the minutes from our (weekly) discussions are kept here. The Synapse Engineering team will consider the GitLab issues to be the ground truth version of the current findings. If the emailed report or Jira issues are different, the GitLab issues are to be taken as authoritative and the other sources will be brought into sync'. Each GitLab issue has a severity (Critical, High, Medium, Low) and a Due Date, which is based on the FISMA remediation timeline. The tags on the GitLab issues can also be used to categorize the issue according to its source:
...
To address findings from StackArmor, the Synapse Engineering team can either (1) update our servers or infrastructure to address the finding, or (2) document that the finding won’t be addressed. When a finding has been addressed, StackArmor's scans and automation will detect the fix, and the issue will automatically close out in GitLab. Similarly Sage’s automation (using Unito.io) will mirror the change to Jira, closing it. Engineers should not manually close these issues. Alternatively, the team can decide not to address an issue if the perceived risk is low and the current behavior is needed for our system to work as intended. (An example might be the public user profiles Synapse provides or the public S3 bucket hosting our RAN.) Such a decision is more likely to be made for low severity issues. Another reason not to address a finding is that a finding is simply incorrect, that the reported security issue does not exist.
...