diff --git a/src/site/markdown/index.md b/src/site/markdown/index.md index b0acd8f8a..72a7b2793 100644 --- a/src/site/markdown/index.md +++ b/src/site/markdown/index.md @@ -14,8 +14,8 @@ libraries in our applications that contain well known published vulnerabilities More information about dependency-check can be found here: -* (How does dependency-check work)[internals.html] -* (How to read the report)[thereport.html] +* [How does dependency-check work](./internals.html) +* [How to read the report](./thereport.html) **IMPORTANT NOTE**: Dependency-check automatically updates itself using the NVD Data Feeds hosted by NIST. **The initial download of the data may take fifteen minutes diff --git a/src/site/markdown/internals.md b/src/site/markdown/internals.md index 3eeeb7086..35433a5e5 100644 --- a/src/site/markdown/internals.md +++ b/src/site/markdown/internals.md @@ -5,7 +5,9 @@ is called Evidence; there are three types of evidence collected: vendor, product JarAnalyzer will collect information from the Manifest, pom.xml, and the package names within the JAR files scanned and it has heuristics to place the information from the various sources into one or more buckets of evidence. -Within the NVD CVE Data (schema can be found [here](http://nvd.nist.gov/schema/nvd-cve-feed_2.0.xsd)) each CVE Entry has a list of vulnerable software: +Within the NVD CVE Data (schema can be found [here](http://nvd.nist.gov/schema/nvd-cve-feed_2.0.xsd)) each CVE Entry has +a list of vulnerable software: + ```xml ... @@ -26,7 +28,7 @@ level that is equal to the lowest level confidence level of evidence used during evidence was used in determining the CPE then the CPE would have a highest confidence level. Because of the way dependency-check works both false positives and false negatives may exist. Please read -(How to read the report)[thereport.html] to get a better understanding of sorting through the false positives and false +[How to read the report](thereport.html) to get a better understanding of sorting through the false positives and false negatives. Dependency-check does not currently use file hashes for identification. If the dependency was built from source the hash diff --git a/src/site/markdown/thereport.md b/src/site/markdown/thereport.md index ab3c31525..21995f8e4 100644 --- a/src/site/markdown/thereport.md +++ b/src/site/markdown/thereport.md @@ -3,8 +3,8 @@ How To Read The Report There is a lot of information contained in the HTML version of the report. When analyzing the results, the first thing one should do is determine if the CPE looks appropriate. Due to the way dependency-check works (see above) the report may contain false positives; these false positives are primarily on the CPE values. If the CPE value is wrong, this is usually obvious and one should use the suppression feature in the report to generate a suppression XML file that can be used on future scans. In addition -to just looking at the CPE values in comparison to the name of the dependency - one may also consider the confidence of the CPE (as discussed in (How does dependency-check -work)[internals.html]). See the (Suppression False Positives)[suppression.html] page for more information on how to generate and use the suppression file. +to just looking at the CPE values in comparison to the name of the dependency - one may also consider the confidence of the CPE (as discussed in [How does dependency-check +work](./internals.html)). See the [Suppressing False Positives](./suppression.html) page for more information on how to generate and use the suppression file. Once you have weeded out any obvious false positives one can then look at the remaining entries and determine if any of the identified CVE entries are actually exploitable in your environment. Determining if a CVE is exploitable in your environment can be tricky - for this I do not currently have any tips other then