Enhanced Component Metadata (Javascript)

[stevespringett]

cdnjs provides some interesting data in their GitHub repo which is originally used to power their website and provide SRI, could be used for component analysis and enhanced metadata.

SRI hash values are provided in their git repo. For example https://github.com/cdnjs/new-website/blob/master/sri/d3/5.9.2.json is the values for the minified and non-minified versions. The SRI can be reversed to retrieve the file hash. For example:

echo "kX9/pjvgpDgSmoSfzAlYJeICaZXca16iu+c3F6ueKRo=" | base64 -D | xxd -p

When a component is imported from a BOM and the only thing we really know about it is the sha256/384/512 hash, we could theoretically perform a reverse lookup to identify an unmanaged javascript component. Having a script that would could:

• Clone https://github.com/cdnjs/new-website
• Recurse through the entire sri directory structure
• Convert the SRI into file hashes
• Store the library/version/hash in a database

Reverse lookups would then be possible. Once a component is identified, we could then use the data from a different repo that provides additional metadata about the project.

For example, the following URL describes the d3 project itself. It includes the latest version, but also includes project description, homepage, git repo, license, and other useful metadata.

https://github.com/cdnjs/cdnjs/blob/master/ajax/libs/d3/package.json

---

While cdnjs is just one way, there may be other ways to do this, and for additional ecosystems. This is a research project with the goal of being able to:

• Identify potentially unmanaged components
• Identify new sources of project metadata
  • Git repo
  • Homepage
  • etc

[mterron]

Would something like this help:

https://github.com/mterron/sri2json

[stevespringett]

@mterron yes, once this is working, it would absolutely help. The script currently attempts to perform the first part of the proposed solution - converting all the SRIs for every component into hashes which could be stored in a database (or SQL insert/update statements could be written to the filesystem).

Note to self:

• Requires GNU Find. It does not work with the find installed on macOS
• Requires jq to be installed

Easiest to run on Linux

[stevespringett]

I don't envision this solution being part of Dependency-Track itself, but I do envision the output from this solution being able to seed existing Dependency-Track installations. For example, an XML or JSON file which could be imported containing all the relevant data or SQL statements which could be fetched and executed during an upgrade or a scheduled task.

[stevespringett]

Another possibility is for OWASP to host a web service containing this information and Dependency-Track would simply leverage the services APIs. Will need to check with the foundation to see if this is possible and inquire about costs.