In order to capture the metric identifier when the training link is clicked, the training link must contain the identifier. Here's the related frontend issue > #353322 (comment 897929840)
Could we please include this information in our securityTrainingUrls GraphQL Query response:
{ project(fullPath: "sec-group/security-reports-ex") { id securityTrainingUrls(identifierExternalIds: ["81", "79"]) { name status url identifier // 👈 the name of the vulnerability } }}
Looking at the response from both our vendors, Kontra and SCW, looks like they do provide this information; both under the name field.
// Sample response from SCW{ url: "https://portal.securecodewarrior.com/?utm_source=partner-integration:gitlab#/website-trial/web/injection/sql/java/spring", name: "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", 👈 description: "..."};// Sample response from Kontra{ name: "Reflected Cross Site Scripting", 👈 "cwe": [ 81, 83, 87 ], "language": "java", "link": "https://application.security/free-application-security-training/owasp-top-10-reflected-cross-site-scripting"}
Since this query will undergo some changes from this > #349606 (closed). I'm placing this as a blocked issue, and we should keep that issue as a priority and we can get tackle this afterward depending on your capacity
Thanks @sming-gitlab for creating this issue. If we just need the name from the external call response in GraphQL api response that can be added here. The backend implementation of this issue should not be blocked by this backend#349606 (closed) issue.
@sming-gitlab@subashis I think I'd rather option 1. This way, the metrics will be consistent with the vulnerability names in the rest of the vulnerability management UI and APIs, right?
@matt_wilson Yes, I think option 1 is a good call That way we're working with normalized data which will be helpful say we needed to compare data down the road -- consistency all the way
Brining this in %14.10 as discussed in our sync meeting @sming-gitlab. We are not probably going to work on #349606 (closed) (which is for %14.10) before doing more research on refinement. Also this work will unblock frontend metric passing issue.
Thanks for letting me know about the priority change, @subashis.
While I was here, I read the description and got confused.
On the API change, which of the identifiers is being return as a value for identifier? The primary_identifier? Or the CWE identifier selected?
Actually, reading Sam's examples, I'm led to believe that we'll pass-through the name returned from the vendor as the identifier, which would be super weird, so I must be getting this wrong.
For reference, I was thinking name: "Reflected Cross Site Scripting" would be returned as identifier: "Reflected Cross Site Scripting".
For the api, it does not check whether it is primary or other identifiers. Right now, we are getting only cwe identifiers name/external_id as a list. We are then returning training urls for each of them if it is available (return first the primary provider one, then follow the other provider). As an example:
From the right hand side of the GraphQL api response, you can see we are not returning anything that can associate the training url to identifier name/external_id. But when frontend is trying to send metrics for clicking in training url, frontend wants to send a metric where identifier name will be there. In most of our case it will be something like: identifier: "CWE-94" one more field in response.
Actually, reading Sam's examples, I'm led to believe that we'll pass-through the name returned from the vendor as the identifier, which would be super weird, so I must be getting this wrong.
We decided to use identifier name that is present in our db. We are not using the name coming from vendor (#357569 (comment 900073006)).
@sming-gitlab tagging you incase if you want to add something here.
@subashis wooooo, thanks for the update on this! I was wondering if it would be better if we could use the exact argument value we pass to you from the frontend (so the pre-parsed raw value)? -- that way when reviewing the metrics, it would be better if we're analyzing consistent data. Is this possible?
I agree with @sming-gitlab's comment above: it seems like we should qualify the value of identifier a bit better to future-proof support for non-CWE identifiers.
was wondering if it would be better if we could use the exact argument value we pass to you from the frontend (so the pre-parsed raw value)? -- that way when reviewing the metrics, it would be better if we're analyzing consistent data. Is this possible?
This is possible. We are right now parsing at the time of initialization that is why the pre-parsed value is lost. I will find a way to hold the pre-parsed value for metrics.
I agree with @sming-gitlab's comment above: it seems like we should qualify the value of identifier a bit better to future-proof support for non-CWE identifiers.
To paraphrase Postel's robustness principle: be strict about what we emit, and flexible on what we accept.
Thanks for the reference. I agree about to show the pre-parsed value will be more consistent.