certspotter VS osv.dev

> 1. Is this proactively monitored for? And how? And by whom?

Yes, security researchers and domain owners use Certificate Transparency Monitors to search for certificates. e.g.:

https://crt.sh/ - allows you to search for certificates for a domain

https://github.com/SSLMate/certspotter/ - open source tool which notifies you when a certificate is issued for one of your domains

https://sslmate.com/certspotter/ - commercial service that does the same, operated by my company

> 2. If a major state-level CA was discovered to have issued a mitm cert, would browser vendors really take the commercial hit of removing or distrusting their root cert?

In 2017, Chrome and Firefox distrusted Symantec, which was at the time the world's largest certificate authority: https://security.googleblog.com/2017/09/chromes-plan-to-dist...

Symantec hadn't even issued MitM certs - they were just grossly incompetent. Distrusting them was very painful, but necessary to upload the integrity of the CA system, and demonstrated conclusively that there is no such thing as a too-big-to-fail CA.

Indeed, a CT monitor which sends alerts about legitimate certificates is pretty much useless due to noise. My service, Cert Spotter, provides an API endpoint[1] which you can upload your CSRs to, so you don't get alerted about certificates using the same key as the CSR. The open source version of Cert Spotter can invoke a script[2] when a certificate is discovered, and the script can cross reference against a list of legitimate certs.

[1] https://sslmate.com/help/reference/certspotter_authorization...

[2] https://github.com/SSLMate/certspotter/blob/master/man/certs...

Is it safe to assume that hashing (1) every file on disk, or (2) any given file on disk at random, will yield random bits with uniform probability; and (3) why Argon2 instead of e.g. only two rounds of SHA256?

https://github.com/google/osv.dev/blob/master/README.md#usin... :

> We provide a Go based tool that will scan your dependencies, and check them against the OSV database for known vulnerabilities via the OSV API. ... With package metadata, not (a file hash, package) database that could be generated from OSV and the actual package files instead of their manifest of already-calculated checksums.

Might as well be heating a pool on the roof with all of this waste heat from hashing binaries build from code of unknown static and dynamic quality.

Add'l useful formats:

> Currently it is able to scan various lockfiles, debian docker containers, SPDX and CycloneDB SBOMs, and git repositories

Also it supports an alternative sources of CVEs with https://osv.dev

https://osv.dev its open source and even has a free API with almost all the popular languages. One of the inspirations for my project.

pyscan uses OSV as its database for now. There are plans to add a few more.

JSON-LD or RDFa (RDF in HTML attributes) in at least the /index.html the HTML footer should be sufficient to indicate that there is structured linked data metadata for crawlers that then don't need an HTTP request to a .well-known URL /.well-known/ai_security_reproducibility_carbon.txt.jsonld.json

OSV is a new format for reporting security vulnerabilities like CVEs and an HTTP API for looking up CVEs from software component name and version. https://github.com/google/osv.dev#third-party-tools-and-inte... :

> We provide a Go based tool that will scan your dependencies, and check them against the OSV database for known vulnerabilities via the OSV API.

> Currently it is able to scan various lockfiles, -- (repo2docker REES config files) -- debian docker containers, SPDX and CycloneDB SBOMs, and git repositories.

Something I've recently worked on is building an SQLite database of all the dependencies my organisation uses, which makes it possible to write our own queries and reports. The tool is all Open Source (https://dmd.tanna.dev) and has a CLI as well as the SQLite data.

Ive used it to look for software that's out of date (via https://endoflife.date), to find vulnerablilities (via https://osv.dev) and get license information (via https://deps.dev)

It's been hugely useful for us understanding use of internal and external dependencies, and I wish I'd built it earlier in my career so I could've had it for other companies I've worked at!

Something like osv-scanner (https://osv.dev/), Github's depandabot etc would help to a great extend in detecting malicious dependencies. Not much else be done I guess

Have a look at https://security.googleblog.com/2022/12/announcing-osv-scanner-vulnerability.html they have plans for c++ https://github.com/google/osv.dev/issues/783