TAP 1.6 – CVE Triage Flow

TAP has many features which help with securing our software supply chain. One of the key elements of security is obviously source code and image scanning which TAP has had since GA, but as we all know, finding the vulnerabilities is one thing, but how to triage these found vulnerabilities is an entire beast in it of itself, and this is actually where a lot of the true pain lies. As per the documentation: The new Triage feature of Tanzu Application Platform allows you to store vulnerability analysis information alongside the current data handled by SCST – Store. Using the Tanzu Insight CLI, users can now perform basic triaging functions against any detected vulnerabilities. The main objective is to reduce spreadsheet and tool toil by centralizing CVE scanning, identification, and triaging in one place. While the current flow is documented as a purely CLI based flow, using the insight plugin for Tanzu CLI, because this is also a fully API driven flow, Hopefully we will see this flow also integrated into a UI based flow in a future release. Currently this is an experimental feature, and will likely change over time as the feature gets more and more usage and feedback from customers, but the idea in it of itself is extremely powerful, and testing it out and providing feedback is a great way to influence the future of the product in this area! What does the flow look like The first step when beginning to triage a new vulnerability, is to find which CVE we are going to triage, and for which image and workload. Lets walk though a simple flow with the new Triage command: tanzu insight triage update \ --cveid $CVE_ID \ --pkg-name $PKG_NAME \ --pkg-version $PKG_VERSION \ --img-digest $IMG_DIGEST \ --artifact-group-uid $WORKLOAD_UID \ --state in_triage As can be seen above, we are setting the specific CVE in question into a triage state. Next once we have done our triage and gathered the information, we can update the triage data in the metadata store by using the triage command again, but this time with all the needed information. When we talk about the information that should be included in triage data this is categorized in the TAP triage flow, into a few key pieces of data: State of the triage – this can be any of the following: resolved = the vulnerability has been remediated. resolved_with_pedigree = the vulnerability has been remediated and evidence of the changes are provided in the affected components pedigree containing verifiable commit history and/or diff(s). exploitable = the vulnerability may be directly or indirectly exploitable. in_triage = the vulnerability is being investigated. false_positive = the vulnerability is not specific to the component or service and was falsely identified or associated. not_affected = the component or service is not affected by the vulnerability. –justification should be specified for all not_affected cases. Justification of the impact anaylsis – this can be any of the following: code_not_present = the code has been removed or tree-shaked. code_not_reachable = the vulnerable code is not invoked at runtime. requires_configuration = exploitability requires a configurable option to be set/unset. requires_dependency = exploitability requires a dependency that is not present. requires_environment = exploitability requires a certain environment which is not present. protected_by_compiler = exploitability requires a compiler flag to be set/unset. protected_at_runtime = exploits are prevented at runtime. protected_at_perimeter = attacks are blocked at physical, logical, or network perimeter. protected_by_mitigating_control = preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability. Response from package maintainer or supplier – can be one or more of the following: can_not_fix will_not_fix update rollback workaround_available A Plain text comment – this can be used to add any additional notes beyond the above options to explain the status and logic behind a decision. With those pieces of data an example of a CVE triage command could be: tanzu insight triage update \ --cveid $CVE_ID \ --pkg-name $PKG_NAME \ --pkg-version $PKG_VERSION \ --img-digest $IMG_DIGEST \ --artifact-group-uid $WORKLOAD_UID \ --state not_affected \ --justification requires_environment \ --response workaround_available \ --comment "This is only exploitable on ARM based processors and we run all K8s on x86 processors" Beyond the basic flow from above, we can also list all CVE triages and there status using the triage list command, as well as copy triage data between images easily using the triage copy command. Summary While this is only a CLI flow, and the UX is still a bit rough, the idea and promise of a solution like this is huge, and it is great to see the direction the TAP team are taking, going beyond just alerting that a vulnerability exists, but trying to assist customers in how to build workflows and processes in order to start to tackle the vulnerabilities found in an organized, and central manner! I’m very excited to see this mature over time, and to see where this ends up evolving over the next few releases!