-
-
Notifications
You must be signed in to change notification settings - Fork 17
Description
In yesterday's call, we discussed a short coming in the current workflow with regards to the discoverability of compliance documents (e.g SOC 2 Type II). The core of this issue is that these are not necessarily related to a product, but instead are properties of the company/organization. In some cases they are, but more often than not they are a product artifact.
@stevespringett provided a good example for a use case where a company is doing due diligence on another company they are evaluating to buy software from. At this point, they don't know what product they are to buy (this is likely determined by a different department and subsequently have no SKU or TEI), but they do want to see if the company is compliant with their procurement requirements (e.g. SOC 2 Type II).
A compliance document fits perfectly well into an artifact, which in turn can be part of a component. However, there is currently no way to query a component without having a component UUID.
TEA Components do however have identifiers like this:
{
"uuid": "3910e0fd-aff4-48d6-b75f-8bf6b84687f0",
"name": "Apache Log4j API",
"identifiers": [
{
"idType": "PURL",
"idValue": "pkg:maven/org.apache.logging.log4j/log4j-api"
}
]
}We could introduce a new idType called something like ComplianceDocument. The value then could be a reserved list, including;
SOC2-Type-IIISO27001
If we then follow the structure that we use for /products, where we can query based on idType using GET parameters, we could use a GET call against /component with ?idType=ComplianceDocument to return all compliance documents, or ?idType=ComplianceDocument&idValue=ISO27001 to just return the ISO27001 documents.
Do however consider this ticket an early draft based on the conversation in yesterday's meeting to get the conversation started.