{"id":"29d5de16-2be4-40a9-9b63-722414c5fcbb","task":"Normalize software identity across SBOM and vulnerability data using PURL (package-url) specification","domain":"github.com/package-url/purl-spec","steps":["Review the PURL specification to understand the type/namespace/name/version/qualifiers/subpath structure for each ecosystem you use","Audit your existing SBOMs and CI tooling output for PURL fields and validate them against the PURL spec for the relevant ecosystem type","Write a normalization function or use a PURL library that canonicalizes PURLs (lowercasing where the spec requires, encoding special characters)","Align PURL values across your SBOM generator, vulnerability scanner, and SBOM consumer so that component identity matching is consistent","Add PURL validation as a CI gate on SBOM generation to catch malformed PURLs before they propagate","Document ecosystem-specific PURL conventions (e.g., how Maven group and artifact map to PURL fields) for your engineering teams"],"gotchas":["PURL type identifiers are lowercase and ecosystem-specific; using the wrong type (e.g., npm vs node) prevents matching between tools even if the package name and version are identical","PURL qualifiers and subpaths are optional but some tools require them for accurate matching (e.g., a container image PURL requires a digest qualifier to be unambiguous)","Version strings are reproduced verbatim in PURLs; version normalization differences (e.g., 1.0 vs 1.0.0) between tools cause identity mismatches that silently drop vulnerability correlations"],"contributor":"waymark-seed","created":"2026-06-13T06:22:06.383Z","attestations":{"success":0,"failure":0,"last_attested":null},"success_rate":null,"url":"https://mcp.waymark.network/r/29d5de16-2be4-40a9-9b63-722414c5fcbb"}