Closed nguforw closed 1 week ago
Hi @nguforw, Thanks for raising the feature request. We have added it into our backlog.
The following is a combined proposal for both the ask for Mitigation status (#61) and Threat status (#126) given the interplay between them.
Ask: @nguforw for your feedback (and anyone else reading this) on if the below proposal would address your use case.
We propose the tool will:
.tc.json
) between deployments, and to maximise the usefulness of any associated 'Insight dashboard' widgets that would be created.threatIdentified
, such that it useful for diffs/PRs for those that use version control methods (which we encourage).tc.json
diffs do not become "noisy".avoids
the risk) - hence we will not include a seperate status for "Risk Accept" it will form part of "Resolved"threatResolved
and threatResolvedNotUseful
respectively.Status in .tc.json export (constant) | UI Label (can be changed in build) | UI Description (can be changed in build) | Comments |
---|---|---|---|
threatIdentified |
"Indentified" (default) - Other possible values you may want in your build could include: "Open", "Active" etc |
"Potential threat has been identified" | All newly added threats get this status |
threatResolved |
"Resolved" (default) - Other possible values you may want in your build include: "Mitigated", "Complete" etc |
"All agreed risk response actions (mitigation, transfer, avoidance, risk acceptance) have been completed aligned to our risk tolerance" | As noted above there is always amount of residual risk acceptance (unless one avoids the risk) - hence we will not include a seperate status for "Risk Accept" it will form part of "Resolved" |
threatResolvedNotUseful |
"Not Useful" (default) - Other possible values you may want in your build could include: "False positive" etc |
"This threat is invalid / not applicable to our use system" | We consider "Resolved" and "NotUseful" as both being outcome state - so both will include the term "Resolved" in their system defined code threatResolved and threatResolvedNotUseful respectively. |
labels
values - with the defaults being : Identified
, Resolved
, NotUseful
)threatIdentified
status.tc.json
files do not have the status automatically set, and will have a runtime-only status of NotSet
(see dashboard section for visibility)threatIndentified
, threatResolved
, threatNotUseful
, NotSet
)threatResolved
where at least one linked mitigation was not marked mitigationResolved
- but given our proposed approach to not differentiate full risk acceptance of a threat versus a partial, this is not possible.mitigationResolved
and mitigationResolvedAbandoned
respectively.Status in .tc.json export (constant) | UI Label (can be changed in build) | UI Description (can be changed in build) | Comments |
---|---|---|---|
mitigationIdentified |
"Indentified" (default) - Other possible values you may want in your build could include: "Idea", "Planned", "Backlog" | "Mitigation has been identified" | All newly added mitigations get this status |
mitigationInProgress |
“In-Progress" (default) - Other possible values you may want in your build include: "Doing" | "Mitigation is in-progress" | |
mitigationResolved |
“Resolved" (default) - Other possible values you may want in your build could include: "Implemented", "Complete","Accepted" etc | “Mitigation has been completed to an agreed scoped” | We do not have the notion of "Partially Resolved" as we see that as" Resolved" where the mitigation has been completed to an agreed scope. Meaning if partial... that was agreed. We capture the outcome only. |
mitigationResolvedAbandoned |
"Abandoned" (default) - Other possible values you may want in your build could include: "Won't do" etc | "Will not be implementing this mitigation" |
labels
values - with the defaults being : Identified
, In-Progress
, Resolved
, Abandoned
).tc.json
files do not have the status automatically set, and will have a runtime-only status of NotSet
(see dashboard section for visibility)mitigationResolved
+ mitigationResolvedAbandoned
) / total
(inc NoSet
))
mitigationIdentified
, mitigationInProgress
,mitigationResolved
, mitigationResolvedAbandoned
, including NotSet
):tada: This issue has been resolved in version 1.0.57 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Describe the feature
I would like to be able to capture the status of any mitigations that are documented within threat composer
Use Case
Mitigations are the "What are we going to do about it?" part of threat modelling. Whilst threat composer allows you to define mitigations, it does leave you with a fair amount of ambiguity regarding the actual status of the mitigations. If a mitigation is captured against a threat, the tool will indicate that the threat has been mitigated. But it fails to capture the fact that the mitigation may not actually have been implemented. This leads to a false sense of security.
Proposed Solution
Add a new "Status" field against each mitigation with the following values:
Other Information
No response
Acknowledgements