Hardenize starts with the domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc).
Before Hardenize, I built SSL Labs.
Hardenize starts with the domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc).
Before Hardenize, I built SSL Labs.
One problem is testing the more bespoke vuln routes - that's to say, the buffer overflows, the old package exploits, the strange oddities. By the sounds of it, you are building an "obvious security pitfalls" testing bot, which is in itself very valuable don't get me wrong, but i'm pushed to say that it's an NP problem to test bespoke vuln routes, which means the kind of testing process you are developing (linear-time problem solver) will struggle with testing the non-linear-time problems of bespoke vulns.
However, I wish you luck, hats off to this, it's a great idea!
To that end, Hardenize doesn't check for vulnerabilities. There's plenty of existing tools that do; I don't want to reinvent that wheel.
Regarding DANE is there a benefit in deploying it now that browser vendors are against it?
Also worth noting is that Key Pinning may be a very sharp knife.