github-mirrors/DependencyCheck
1
0
Fork 0
mirror of https://github.com/ysoftdevs/DependencyCheck.git synced 2026-01-14 07:43:40 +01:00
Code Issues Packages Projects Releases Wiki Activity

corrected link syntax

Browse Source 
Former-commit-id: 01b9ea03864248a9c5427af6d7238c435c0a4fa7
This commit is contained in:
Jeremy Long
2014-08-05 18:45:25 -04:00
parent 56b447493e
commit fe19c97d86
3 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/site/markdown/index.md
View File

@@ -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

6
src/site/markdown/internals.md
View File

@@ -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
<entry id="CVE-2012-5055">
...
@@ -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

4
src/site/markdown/thereport.md
View File

@@ -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