I am working on security automation - checking web application for the OWASP top 10 vulnerabilities. I'd like to check for the respective description, CWE-IDs etc and make decisions automatically. I can imagine a machine-readable representation of the top 10 OWASP vulnerabilities that supports security automation. Are there efforts to provide this information in machine readable formats e.g. json or yaml. How do vulnerability scanners support the top ten, what methodologies are used?

  • I don't believe this question to be on topic for the site. Asking where you can find x piece of documentation isn't really a security question. – J.J Jun 19 '18 at 11:58
  • Automation of Vulnerability Analysis is pretty much not entertained. – Anonymous Platypus Jun 19 '18 at 11:59
  • @JoshuaJones What if i intend using the information for security risk assessment e.g. better integration into security methods and improving existing security analytical approaches. Do I ask developers or network admins ... which other community has the expertise and knowledge about this ? What is the idea of SCAP (csrc.nist.gov/Projects/Security-Content-Automation-Protocol) ....security automation is a core part of security ! – SyCode Jun 19 '18 at 12:07
  • 1
    Whilst you may be using the knowledge gained to carry out a security function, you're asking us where to find a document/if it exists. Whilst someone might be able to tell you the question doesn't fit the site. – J.J Jun 19 '18 at 12:10
  • @JoshuaJones As far as I know, the creators of OWASP Top 10 fit this site as well as most people who use it technically and otherwise. The question also, does not terminate at whether or not the document exists, it spans to methodologies and tools given that those who are directly involved in such things use some form of methods. – SyCode Jun 19 '18 at 12:53

It's a good idea to want to approach this problem with automation. The OWASP list itself, however, is not a list of vulnerabilities, where a vulnerability is a known bad version of publicly-released software or known bad configuration that can be scanned for, identified and rectified.

Instead, it is a list of what OWASP calls risks, which are classes of security failures that have led to compromise and loss. In other words, each OWASP item is a higher level abstraction, not an individual, identifiable vulnerability.

Also, many of the vulnerabilities that can be classified under one or another OWASP risk are themselves abstract, and not necessarily easy to scan for.

For instance, there are code patterns that are recommended to help prevent SQL Injection (one class of vulnerability under the Injection risk, the #1 risk now for many years)- like, use prepared statements. However, not all application code that does not use prepared statements is vulnerable to SQL Injection.

From an automation perspective, source code scanning tools known as "static analyzers" specialize in finding suboptimal code patterns- suboptimal both from a security perspective and also from an idiom/tech debt perspective. In my experience, they require an enormous configuration investment and still often only yield barely usable results.

Standing up automation for application security scanning as a whole is not a solved problem, depending only on the availability of machine readable resources. We are still in the banging-stones-together-to-haphazardly-make-fire stage of application security.

Perhaps the most automatable risk is risk #9, using components with known vulnerabilities. Every language platform now has tooling to check versions of libraries in use in a particular codebase against a list of libraries flagged for having known vulnerabilities. Which is great.

However- enormous respect to the overworked folks who without reward or fame toil in these areas- these latter lists are not exhaustive, comprehensive, or definitive. That a particular library doesn't have a vulnerability associated with it doesn't mean one doesn't exist. It more often means vulnerabilities exist but they just haven't been a) found or b) reported.

Overall it's a pretty poor state of affairs, and again, that particular risk is probably where current state of automation is strongest.

To close on a hopeful note, there are a number of promising projects. One that I keep my eyes on is Google's Grafeas:


Its goal is to support the promulgation of machine readable metadata artifacts, from which an application security pipeline can be constructed. It is not close to production ready, but is progressing.

  • thank you very much for providing a very comprehensive response to my question. Infact, you have brought to the fore several issues militating against information security. Generally, information security lags behind core development in terms of tooling, methods and adaptation to emerging technologies ! My question was motivated due to lack of machine readable format of the OWASP top 10. continued below – SyCode Jun 20 '18 at 11:57
  • For example, on T10 - A1 references four CWE-IDs (CWE-77, CWE-89, CWE-564 and CWE-917). A1 is scored ` 8.0, though the threat agent and business impact metrics are left out (these are environment specific). If these are scored, the scores are then effectively adapted to the target environment. Hence, other vulnerabilities could be assigned scores based on which category they fall into. A challenge with this method might be those CWEs not on the list, and for these ones lower scores could be assigned. However, there is no way to automatically grab these information in the current format – SyCode Jun 20 '18 at 12:01
  • That is generally true, and I completely agree, though I am aware of efforts to normalize and classify vulnerabilities into a schema and categorize them under the OWASP top 10. There had been some open source/open data folks doing this but I think now it is all commercial. Can dig out references if helpful. However, it's important to note that have a machine readable list of CWE-IDs classified under OWASP risks does not mean that one solves for OWASP by just checking those CWEs. The CWEs only represent what's known and reported, which is a small subset of the total risk space. – Jonah Benton Jun 20 '18 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.