OWASP - User contributions [en]

OWASP Dependency Track Project

2019-12-16T21:27:49Z

Steve Springett: /* Features */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks application, library, framework, operating system, and hardware components
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Gems (Ruby)
** Hex (Erlang/Elixir)
** Maven (Java)
** NPM (Javascript)
** NuGet (.NET)
** Pypi (Python)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] Software Bill-of-Materials (SBOM) formats
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in OpenAPI format
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [16 Dec 2019] v3.7.0 Released
* [01 Oct 2019] v3.6.1 Released
* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released


== Community Integrations ==
* [https://github.com/ozonru/dtrack-audit dtrack-audit]
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-12-16T07:24:34Z

Steve Springett: /* Features */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks application, library, framework, operating system, and hardware components
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Hex (Erlang/Elixir)
** Gems (Ruby)
** Maven (Java)
** NPM (Javascript)
** NuGet (.NET)
** Pypi (Python)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] Software Bill-of-Materials (SBOM) formats
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in OpenAPI format
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [16 Dec 2019] v3.7.0 Released
* [01 Oct 2019] v3.6.1 Released
* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released


== Community Integrations ==
* [https://github.com/ozonru/dtrack-audit dtrack-audit]
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

File:Integrations.png

2019-12-16T07:22:55Z

Steve Springett: Steve Springett uploaded a new version of File:Integrations.png

Dependency-Track Ecosystem and Integrations

OWASP Dependency Track Project

2019-12-16T07:21:19Z

Steve Springett: /* News and Events */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks application, library, framework, operating system, and hardware components
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] Software Bill-of-Materials (SBOM) formats
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in OpenAPI format
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [16 Dec 2019] v3.7.0 Released
* [01 Oct 2019] v3.6.1 Released
* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released


== Community Integrations ==
* [https://github.com/ozonru/dtrack-audit dtrack-audit]
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-10-14T21:30:14Z

Steve Springett: added dtrack-audit

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks application, library, framework, operating system, and hardware components
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] Software Bill-of-Materials (SBOM) formats
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in OpenAPI format
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released


== Community Integrations ==
* [https://github.com/ozonru/dtrack-audit dtrack-audit]
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-09-29T06:27:03Z

Steve Springett: doc update

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks application, library, framework, operating system, and hardware components
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] Software Bill-of-Materials (SBOM) formats
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in OpenAPI format
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released


== Community Integrations ==
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-09-29T06:25:18Z

Steve Springett: case

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [[OWASP Dependency Check|Dependency-Check]] reports to simplify the transition to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released


== Community Integrations ==
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-09-29T06:23:51Z

Steve Springett: /* News and Events */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBoM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [[OWASP Dependency Check|Dependency-Check]] reports to simplify the transition to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [28 Sep 2019] v3.6.0 Released
* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released


== Community Integrations ==
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Software Component Verification Standard

2019-08-28T23:00:07Z

Steve Springett: incubating docs

User:Steve Springett

2019-08-28T20:29:43Z

Steve Springett: minor update to bio

[[File:Steve Springett.jpg|left||thumb]] Steve educates teams on the strategy and specifics of developing secure software.
He practices security at every stage of the development lifecycle by leading sessions on threat modeling, secure architecture and design, static/dynamic/component analysis, offensive research, and defensive programming techniques.

Steve's passionate about helping organizations identify and reduce risk from the use of third-party and open source components. He is an open source advocate and leads the [[OWASP Dependency Track Project|OWASP Dependency-Track project]], [https://cyclonedx.org/ CycloneDX] bill-of-material specification, and participates in several related projects and working groups.

OWASP Software Component Verification Standard

2019-08-28T20:24:22Z

Steve Springett: incubating docs

OWASP Software Component Verification Standard

2019-08-28T20:23:55Z

Steve Springett: incubating docs

OWASP Software Component Verification Standard

2019-08-28T19:55:22Z

Steve Springett: incubating docs

OWASP Software Component Verification Standard

2019-08-28T19:51:38Z

Steve Springett: incubating docs

OWASP Software Component Verification Standard

2019-08-28T19:40:34Z

Steve Springett: incubating docs

=Main=
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Software Component Verification Standard==
This project is currently incubating... Stay tuned.

==Description==
<span style="color:#ff0000">
This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.
</span>

The Documentation Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Documentation project. After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red. Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category. The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.

Creating a new set of project pages from scratch can be a challenging task. By providing a sample layout, with instructional text and examples, the OWASP Documentation Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.

Contextual custom dictionary builder with character substitution and word variations for pen-testers

==Licensing==
<span style="color:#ff0000">
A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.
</span>

This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html link GNU Affero General Public License 3.0] as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}.

==Getting Involved==
<span style="color:#ff0000">
Involvement in the development and promotion of <strong>Documentation Project Template</strong> is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Project Resources ==

[https://github.com/OWASP/Software-Component-Verification-Standard GitHub Repository]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==
<span style="color:#ff0000">
This is where you can link to other OWASP Projects that are similar to yours.
</span>
* [[OWASP_Code_Project_Template]]
* [[OWASP_Tool_Project_Template]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Document]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[Image:Creative%20Commons.png| 90px | link=https://creativecommons.org/licenses/by-sa/3.0/| Creative Commons Attribution ShareAlike 3.0 License]]
|}
|}

=Roadmap=
As of August, 2019, the highest priority is to get a usable rough draft which can be iterated on by December 31, 2019.

=Project About=
<span style="color:#ff0000">
{{:Template:Project About
|project_name=Software Component Verification Standard
|leader_name1=Steve Springett
|leader_email1=steve.springett@owasp.org
|project_license=Creative Commons Attribution ShareAlike 3.0 License
}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Document]]

OWASP Software Component Verification Standard

2019-08-28T19:35:05Z

Steve Springett: incubating docs

=Main=
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==Project About==
<span style="color:#ff0000">
{{:Template:Project About
|project_name=Software Component Verification Standard
|leader_name1=Steve Springett
|leader_email1=steve.springett@owasp.org
|project_license=Creative Commons Attribution ShareAlike 3.0 License
}}

==OWASP Documentation Project Template==
<span style="color:#ff0000">
This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable. Some readers may be discouraged from looking further at the project if they do not understand the significance of the security concern that is being addressed, so provide enough context so the average reader will continue on with reading the description. You shouldn't assume the reader will understand the objective by providing security terminology, e.g. this project builds cryptographic algorithms, but should also endeavor to explain what they are used for.
</span>

The OWASP Documentation Template Project is a template designed to help Project Leaders create suitable project pages for OWASP Projects. By following the instructional text in red (and then deleting it) it should be easier to understand what information OWASP and the project users are looking for. And it's easy to get started by simply creating a new project from the appropriate project template.

==Description==
<span style="color:#ff0000">
This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.
</span>

The Documentation Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Documentation project. After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red. Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category. The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.

Creating a new set of project pages from scratch can be a challenging task. By providing a sample layout, with instructional text and examples, the OWASP Documentation Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.

Contextual custom dictionary builder with character substitution and word variations for pen-testers

==Licensing==
<span style="color:#ff0000">
A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.
</span>

This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html link GNU Affero General Public License 3.0] as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}.

==Roadmap==
<span style="color:#ff0000">
As of August, 2019, the highest priority is to get a usable rough draft which can be iterated on by December 31, 2019.

==Getting Involved==
<span style="color:#ff0000">
Involvement in the development and promotion of <strong>Documentation Project Template</strong> is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Project Resources ==

[https://github.com/OWASP/Software-Component-Verification-Standard GitHub Repository]

== Project Leader ==

[mailto://steve.springett@owasp.org Steve Springett]

== Related Projects ==
<span style="color:#ff0000">
This is where you can link to other OWASP Projects that are similar to yours.
</span>
* [[OWASP_Code_Project_Template]]
* [[OWASP_Tool_Project_Template]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Document]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[Image:Creative%20Commons.png| 90px | link=https://creativecommons.org/licenses/by-sa/3.0/| Creative Commons Attribution ShareAlike 3.0 License]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Document]]

OWASP Dependency Track Project

2019-08-01T15:54:53Z

Steve Springett: Added community integrations. Limiting news to last five items.

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBoM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [[OWASP Dependency Check|Dependency-Check]] reports to simplify the transition to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released


== Community Integrations ==
* [https://github.com/pmckeown/dependency-track-maven-plugin Dependency-Track Maven plugin]

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-07-21T21:31:11Z

Steve Springett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBoM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [[OWASP Dependency Check|Dependency-Check]] reports to simplify the transition to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [17 Jul 2019] v3.5.1 Released
* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-06-19T22:24:56Z

Steve Springett: desc

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBoM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [[OWASP Dependency Check|Dependency-Check]] reports to simplify the transition to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-06-19T21:55:24Z

Steve Springett: updated description

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Dependency-Track is an intelligent Software [[Component Analysis|Supply Chain Component Analysis]] platform that allows organizations to identify and reduce risk from the use of third-party and open source components. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill-of-Materials (SBoM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

Dependency-Track monitors component usage across all versions of every application in its portfolio in order to proactively identify risk across an organization. The platform has an API-first design and is ideal for use in Continuous Integration (CI) and Continuous Delivery (CD) environments.

[[File:Integrations.png|frameless]]

==Features==
* Tracks component usage across all version of every application in an organizations portfolio
* Identifies multiple forms of risk including
** Components with known vulnerabilities
** Out-of-date components
** Modified components
** License risk
** More coming soon...
* Integrates with multiple sources of vulnerability intelligence including:
** [https://nvd.nist.gov National Vulnerability Database] (NVD)
** [https://www.npmjs.com/advisories NPM Public Advisories]
** [https://ossindex.sonatype.org Sonatype OSS Index]
** [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]
** More coming soon.
* Ecosystem agnostic with built-in repository support for:
** Ruby Gems
** Maven
** NPM
** NuGet
** Python (Pypi)
** More coming soon.
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports importing of [https://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] software bill-of-materials
* Supports importing of [Dependency-Check] reports to simplify transitioning to SBoMs
* Easy to read metrics for components, projects, and portfolio
* Native support for Kenna Security, Fortify SSC, and ThreadFix
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-06-09T17:46:59Z

Steve Springett: 3.5.0 release

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://plugins.jenkins.io/dependency-track Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [07 Jun 2019] v3.5.0 Released
* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2019-05-11T07:05:29Z

Steve Springett: /* News and Events */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://plugins.jenkins.io/dependency-track Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [16 Apr 2019] v3.4.1 Released
* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Check

2019-04-05T18:16:25Z

Steve Springett: /* Integrations */ Updated SQ plugin URL. Added Circle CI Orb

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
==OWASP Dependency-Check==

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently, Java and .NET are supported; additional experimental support has been added for Ruby, Node.js, Python, and limited support for C/C++ build systems (autoconf and cmake). The tool can be part of a solution to the [[Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities | OWASP Top 10 2017 A9-Using Components with Known Vulnerabilities]] previously known as [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | OWASP Top 10 2013 A9-Using Components with Known Vulnerabilities]].

==Introduction==

The OWASP Top 10 2013 contains a new entry: [[Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities | A9-Using Components with Known Vulnerabilities]]. Dependency Check can currently be used to scan applications (and their dependent libraries) to identify any known vulnerable components.

The problem with using known vulnerable components was described very well in a paper by Jeff Williams and Arshan Dabirsiaghi titled, "[https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf Unfortunate Reality of Insecure Libraries]". The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the [https://nvd.nist.gov/vuln/search National Vulnerability Database]).

Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. The core engine contains a series of analyzers that inspect the project dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the [https://nvd.nist.gov/products/cpe Common Platform Enumeration (CPE)] for the given dependency. If a CPE is identified, a listing of associated [https://cve.mitre.org/ Common Vulnerability and Exposure (CVE)] entries are listed in a report.

Dependency-check automatically updates itself using the [https://nvd.nist.gov/vuln/data-feeds NVD Data Feeds] hosted by NIST. '''IMPORTANT NOTE:''' The initial download of the data may take ten minutes or more. If you run the tool at least once every seven days, only a small XML file needs to be downloaded to keep the local copy of the data current.

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Quick Download ==

Version 4.0.2
* [https://dl.bintray.com/jeremy-long/owasp/dependency-check-4.0.2-release.zip Command Line]
* [https://dl.bintray.com/jeremy-long/owasp/dependency-check-ant-4.0.2-release.zip Ant Task]
* [https://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-maven%7C4.0.2%7Cmaven-plugin Maven Plugin]
* [https://search.maven.org/#artifactdetails%7Corg.owasp%7Cdependency-check-gradle%7C4.0.2%7Cgradle-plugin Gradle Plugin]
* [https://plugins.jenkins.io/dependency-check-jenkins-plugin Jenkins Plugin]
* [https://brew.sh/ Mac Homebrew]:<br><code>brew update && brew install dependency-check</code>

Other Plugins
* [https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22net.vonbuchholtz%22%20a%3A%22sbt-dependency-check%22 sbt Plugin]
* [https://github.com/livingsocial/lein-dependency-check lein-dependency-check]

== Integrations ==
* [https://github.com/SonarSecurityCommunity/dependency-check-sonar-plugin SonarQube Plugin]
* [https://github.com/entur/owasp-orb Circle CI Orb]

== Links ==

* [https://github.com/jeremylong/DependencyCheck github]
* [https://github.com/jeremylong/dependency-check-gradle gradle source]
* [https://github.com/albuch/sbt-dependency-check sbt source]
* [https://github.com/jenkinsci/dependency-check-plugin jenkins source]
* [https://www.ohloh.net/p/dependencycheck Ohloh]
* [https://bintray.com/jeremy-long/owasp Bintray]

== Documentation ==

* [https://jeremylong.github.io/DependencyCheck/ Documentation (on GitHub)]

== Mailing List ==

* [mailto:dependency-check+subscribe@googlegroups.com Subscribe]
* [mailto:dependency-check@googlegroups.com Post]
* [https://groups.google.com/forum/#!forum/dependency-check Archived Posts]

== Presentation ==

* [https://jeremylong.github.io/DependencyCheck/general/dependency-check.pdf dependency-check (PDF)]
* [https://jeremylong.github.io/DependencyCheck/general/dependency-check.pptx dependency-check (PPTX)]

==Classifications==

{| width="200" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]
| align="center" valign="top" width="50%" | [[File:Owasp-builders-small.png|link=]]
|-
| align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
|-
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=https://creativecommons.org/licenses/by-sa/3.0/]]
|-
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]
|}

|}

= Acknowledgements =
==Volunteers==
Dependency-Check is developed by a team of volunteers. The primary contributors to date have been:

* [[User:Jeremy Long|Jeremy Long]]
* [[User:Steve Springett|Steve Springett]]
* [[User:Will Stranathan|Will Stranathan]]

= Road Map and Getting Involved =
As of March 2015, the top priorities are:
* Resolving all open [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues/feature requests]
* Improving analysis for .NET DLLs

Involvement in the development and promotion of dependency-check is actively encouraged! You do not have to be a security expert in order to contribute. How you can help:
* Use the tool
* Provide feedback via the [https://groups.google.com/forum/?fromgroups#!forum/dependency-check mailing list] or by creating [https://github.com/jeremylong/DependencyCheck/issues?state=open github issues] (both bugs and feature requests are encouraged)
* The project source code is hosted on [https://github.com/jeremylong/DependencyCheck/ github] - if you are so inclined fork it and provide push requests!

__NOTOC__ <headertabs></headertabs>

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP_Document]]

Component Analysis

2019-03-31T02:54:37Z

Steve Springett: /* Recommendations */

Modern software is assembled using third-party and open source components, glued together in complex and unique ways, and integrated with original code to provide the desired functionality. Third-party (including commercially licensed, proprietary, and "source available" software) along with open source components provide the necessary building blocks that allow organizations to deliver value, improve quality, reduce risk and time-to-market. The benefits of open source are many. However, by using open source components, organizations ultimately take responsibility for code they did not write. Strategic alliances between organizations and open source projects can lead to healthy open source usage and overall risk reduction.

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Inventory =====
Having an accurate inventory of all third-party and open source components is pivotal for risk identification. Without such knowledge, other factors of Component Analysis become impractical to determine with high confidence. Use of dependency management solutions and/or [[#Software Bill-of-Materials (SBOM)|Software Bill-of-Materials (SBOM)]] can aid in inventory creation.

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the [[#Component Type|type of component]], the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components may improve quality or performance. These improvements can be inherited by the applications that have a dependency on them. Components that are end-of-life (EOL) or end-of-support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to [https://semver.org/ Semantic Versioning] terminology, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in a components API may result in longer remediation times if the components have not been continuously updated. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Outdated version identification may leverage ecosystem-specific repositories and is achievable through the use of dependency managers or [[#Component Identification|Package URL]]. Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Evaluating the type should be part of every Component Analysis strategy.

===== Component Function =====
Identifying and analyzing the purpose of each component may reveal the existence of components with duplicate or similar functionality. For example, it's unlikely an application would need multiple XML parsers or cryptographic providers. Potential risk can be reduced by minimizing the number of components for each function and by choosing the highest quality components for each function. Evaluating component function should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The operational and maintenance cost of using open source will increase with the adoption of every new component. The impact can be significantly higher with micro-module ecosystems when there are hundreds or thousands of applications in a given environment. In addition to increased operational and maintenance cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree (sometimes referred to as 'provenance') refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the ''chain of custody''. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation. Component pedigree includes all supporting documentation of lineage and the attributes which make a component unique.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Bill-of-Materials (SBOM) ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients in a recipe. Both are an implementation of transparency.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple SBOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Standardize on a single component for each component function
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of software bill-of-materials (SBOM) for all deliverables
* Leverage Package URL for describing components within SBOMs
* Contractually require SBOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a SBOM
* Import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.insignary.com/ Clarity] || tool_owner = Insignary || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://fossa.com/ FOSSA] || tool_owner = FOSSA || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

*https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
*https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://medium.com/@steve_springett/using-software-bill-of-materials-to-drive-change-and-reduce-risk-5901b7a339e3 - Using Software Bill-of-Materials to drive change and reduce risk
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-03-31T02:52:42Z

Steve Springett: Separated out function from type. Added some clarifications and feedback from community

Modern software is assembled using third-party and open source components, glued together in complex and unique ways, and integrated with original code to provide the desired functionality. Third-party (including commercially licensed, proprietary, and "source available" software) along with open source components provide the necessary building blocks that allow organizations to deliver value, improve quality, reduce risk and time-to-market. The benefits of open source are many. However, by using open source components, organizations ultimately take responsibility for code they did not write. Strategic alliances between organizations and open source projects can lead to healthy open source usage and overall risk reduction.

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Inventory =====
Having an accurate inventory of all third-party and open source components is pivotal for risk identification. Without such knowledge, other factors of Component Analysis become impractical to determine with high confidence. Use of dependency management solutions and/or [[#Software Bill-of-Materials (SBOM)|Software Bill-of-Materials (SBOM)]] can aid in inventory creation.

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the [[#Component Type|type of component]], the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components may improve quality or performance. These improvements can be inherited by the applications that have a dependency on them. Components that are end-of-life (EOL) or end-of-support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to [https://semver.org/ Semantic Versioning] terminology, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in a components API may result in longer remediation times if the components have not been continuously updated. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Outdated version identification may leverage ecosystem-specific repositories and is achievable through the use of dependency managers or [[#Component Identification|Package URL]]. Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Evaluating the type should be part of every Component Analysis strategy.

===== Component Function =====
Identifying and analyzing the purpose of each component may reveal the existence of components with duplicate or similar functionality. For example, it's unlikely an application would need multiple XML parsers or cryptographic providers. Potential risk can be reduced by minimizing the number of components for each function and by choosing the highest quality components for each function. Evaluating component function should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The operational and maintenance cost of using open source will increase with the adoption of every new component. The impact can be significantly higher with micro-module ecosystems when there are hundreds or thousands of applications in a given environment. In addition to increased operational and maintenance cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree (sometimes referred to as 'provenance') refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the ''chain of custody''. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation. Component pedigree includes all supporting documentation of lineage and the attributes which make a component unique.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Bill-of-Materials (SBOM) ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients in a recipe. Both are an implementation of transparency.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple SBOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Standardize on a single component for each component type
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of software bill-of-materials (SBOM) for all deliverables
* Leverage Package URL for describing components within SBOMs
* Contractually require SBOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a SBOM
* Import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.insignary.com/ Clarity] || tool_owner = Insignary || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://fossa.com/ FOSSA] || tool_owner = FOSSA || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

*https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
*https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://medium.com/@steve_springett/using-software-bill-of-materials-to-drive-change-and-reduce-risk-5901b7a339e3 - Using Software Bill-of-Materials to drive change and reduce risk
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Supply Chain Component Analysis

2019-03-30T01:53:27Z

Steve Springett: Redirected page to Component Analysis

#REDIRECT [[Component Analysis]]

Component Analysis

2019-03-21T22:58:23Z

Steve Springett: Added tool: Clarity

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Inventory =====
Having an accurate inventory of all third-party and open source components is pivotal for risk identification. Without such knowledge, other factors of Component Analysis become impractical to determine with high confidence. Use of dependency management solutions and/or [[#Software Bill-of-Materials (SBOM)|Software Bill-of-Materials (SBOM)]] can aid in inventory creation.

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the [[#Component Type|type of component]], the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are end-of-life (EOL) or end-of-support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to [https://semver.org/ Semantic Versioning] terminology, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in a components API may result in longer remediation times if the components have not been continuously updated. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Component type may also be used to determine if duplicate or similar functionally exists. For example, it's unlikely an application would need multiple XML parsers or cryptographic libraries. Risk can be reduced by minimizing the number of components for a given type. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree (sometimes referred to as 'provenance') refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation. Component pedigree includes all supporting documentation of lineage and the attributes which make a component unique.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Bill-of-Materials (SBOM) ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple SBOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Standardize on a single component for each component type
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of software bill-of-materials (SBOM) for all deliverables
* Leverage Package URL for describing components within SBOMs
* Contractually require SBOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a SBOM
* Import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.insignary.com/ Clarity] || tool_owner = Insignary || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://fossa.com/ FOSSA] || tool_owner = FOSSA || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

*https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
*https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://medium.com/@steve_springett/using-software-bill-of-materials-to-drive-change-and-reduce-risk-5901b7a339e3 - Using Software Bill-of-Materials to drive change and reduce risk
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-03-19T22:32:34Z

Steve Springett: Added FOSSA

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Inventory =====
Having an accurate inventory of all third-party and open source components is pivotal for risk identification. Without such knowledge, other factors of Component Analysis become impractical to determine with high confidence. Use of dependency management solutions and/or [[#Software Bill-of-Materials (SBOM)|Software Bill-of-Materials (SBOM)]] can aid in inventory creation.

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the [[#Component Type|type of component]], the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are end-of-life (EOL) or end-of-support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to [https://semver.org/ Semantic Versioning] terminology, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in a components API may result in longer remediation times if the components have not been continuously updated. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Component type may also be used to determine if duplicate or similar functionally exists. For example, it's unlikely an application would need multiple XML parsers or cryptographic libraries. Risk can be reduced by minimizing the number of components for a given type. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree (sometimes referred to as 'provenance') refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation. Component pedigree includes all supporting documentation of lineage and the attributes which make a component unique.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Bill-of-Materials (SBOM) ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple SBOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Standardize on a single component for each component type
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of software bill-of-materials (SBOM) for all deliverables
* Leverage Package URL for describing components within SBOMs
* Contractually require SBOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a SBOM
* Import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://fossa.com/ FOSSA] || tool_owner = FOSSA || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

*https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
*https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://medium.com/@steve_springett/using-software-bill-of-materials-to-drive-change-and-reduce-risk-5901b7a339e3 - Using Software Bill-of-Materials to drive change and reduce risk
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-03-19T21:38:26Z

Steve Springett: Added component inventory and clarifications to existing risks. Removed from draft

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Inventory =====
Having an accurate inventory of all third-party and open source components is pivotal for risk identification. Without such knowledge, other factors of Component Analysis become impractical to determine with high confidence. Use of dependency management solutions and/or [[#Software Bill-of-Materials (SBOM)|Software Bill-of-Materials (SBOM)]] can aid in inventory creation.

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the [[#Component Type|type of component]], the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are end-of-life (EOL) or end-of-support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to [https://semver.org/ Semantic Versioning] terminology, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in a components API may result in longer remediation times if the components have not been continuously updated. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Component type may also be used to determine if duplicate or similar functionally exists. For example, it's unlikely an application would need multiple XML parsers or cryptographic libraries. Risk can be reduced by minimizing the number of components for a given type. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree (sometimes referred to as 'provenance') refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation. Component pedigree includes all supporting documentation of lineage and the attributes which make a component unique.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Bill-of-Materials (SBOM) ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple SBOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Standardize on a single component for each component type
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of software bill-of-materials (SBOM) for all deliverables
* Leverage Package URL for describing components within SBOMs
* Contractually require SBOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a SBOM
* Import SBOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

*https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
*https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://medium.com/@steve_springett/using-software-bill-of-materials-to-drive-change-and-reduce-risk-5901b7a339e3 - Using Software Bill-of-Materials to drive change and reduce risk
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-01-08T17:23:42Z

Steve Springett: Added Renovate to tool listing

<big>DRAFT</big>

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the type of component, the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are End-of-Life (EOL) or End-of-Support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to the [https://semver.org/ Semantic Versioning] nomenclature, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in APIs can negatively impact an organizations ability to respond to emerging vulnerabilities. When a vulnerability is published affecting a wide range of versions but the fix is immediately available only in newer versions, changes in a components API may result in longer remediation times. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation.

Verification and validation of component pedigree is typically reserved for applications with a low tolerance for risk.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Transparency ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency, designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple BOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating BOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of bill-of-materials (BOM) for all deliverables
* Leverage Package URL for describing components within BOMs
* Contractually require BOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a BOM
* Import BOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://renovatebot.com/ Renovate ] || tool_owner = Key Location || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

* https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
* https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-01-08T04:52:46Z

Steve Springett: Removed several occurrances of hardware - keeping just brief mentions of hardware

<big>DRAFT</big>

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the type of component, the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are End-of-Life (EOL) or End-of-Support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to the [https://semver.org/ Semantic Versioning] nomenclature, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in APIs can negatively impact an organizations ability to respond to emerging vulnerabilities. When a vulnerability is published affecting a wide range of versions but the fix is immediately available only in newer versions, changes in a components API may result in longer remediation times. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation.

Verification and validation of component pedigree is typically reserved for applications with a low tolerance for risk.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Transparency ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency, designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple BOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating BOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of bill-of-materials (BOM) for all deliverables
* Leverage Package URL for describing components within BOMs
* Contractually require BOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a BOM
* Import BOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

* https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
* https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-01-08T04:45:24Z

Steve Springett: added additional tools

<big>DRAFT</big>

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the type of component (hardware or software), the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers. Reliability engineers will also site a lower Mean Time to Failure (MTTF) and Mean Time Between Failures (MTBF) on older hardware components.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are End-of-Life (EOL) or End-of-Support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to the [https://semver.org/ Semantic Versioning] nomenclature, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in APIs can negatively impact an organizations ability to respond to emerging vulnerabilities. When a vulnerability is published affecting a wide range of versions but the fix is immediately available only in newer versions, changes in a components API may result in longer remediation times. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Hardware components also come in both serviceable and non-serviceable varieties, each having varying degrees of risk. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation.

Verification and validation of component pedigree is typically reserved for applications with a low tolerance for risk.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Transparency ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency, designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple BOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating BOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of bill-of-materials (BOM) for all deliverables (hardware and software)
* Leverage Package URL for describing components within BOMs
* Contractually require BOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a BOM
* Import BOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://clearlydefined.io/ ClearlyDefined] || tool_owner = Open Source Initiative || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://grafeas.io/ Grafeas] || tool_owner = Grafeas || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://greenkeeper.io/ Greenkeeper] || tool_owner = Greenkeeper || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/heremaps/oss-review-toolkit OSS Review Toolkit] || tool_owner = HERE || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://ionchannel.io/ Ion Channel SA] || tool_owner = Ion Channel || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [http://mergebase.com MergeBase ] || tool_owner = MergeBase || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

* https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
* https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Component Analysis

2019-01-06T06:11:09Z

Steve Springett: added purl to recommendation

<big>DRAFT</big>

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the type of component (hardware or software), the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers. Reliability engineers will also site a lower Mean Time to Failure (MTTF) and Mean Time Between Failures (MTBF) on older hardware components.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are End-of-Life (EOL) or End-of-Support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to the [https://semver.org/ Semantic Versioning] nomenclature, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in APIs can negatively impact an organizations ability to respond to emerging vulnerabilities. When a vulnerability is published affecting a wide range of versions but the fix is immediately available only in newer versions, changes in a components API may result in longer remediation times. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Hardware components also come in both serviceable and non-serviceable varieties, each having varying degrees of risk. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation.

Verification and validation of component pedigree is typically reserved for applications with a low tolerance for risk.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Transparency ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency, designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple BOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating BOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of bill-of-materials (BOM) for all deliverables (hardware and software)
* Leverage Package URL for describing components within BOMs
* Contractually require BOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a BOM
* Import BOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

* https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
* https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

Software Composition Analysis

2019-01-06T06:03:33Z

Steve Springett: Initial commit

#REDIRECT [[Component Analysis]]

Component Analysis

2019-01-06T05:59:12Z

Steve Springett: Initial commit

<big>DRAFT</big>

Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components. Component Analysis is a function within an overall [https://csrc.nist.gov/projects/supply-chain-risk-management Cyber Supply Chain Risk Management] (C-SCRM) framework. A software-only subset of Component Analysis with limited scope is commonly referred to as Software Composition Analysis (SCA).

Any component that has the potential to adversely impact cyber supply-chain risk is a candidate for Component Analysis.

== Common Risk Factors ==

===== Component Age =====
Components may have varying degrees of age acceptance criteria. Factors that impact acceptable age include the type of component (hardware or software), the ecosystem the component is a part of (Maven, NPM, etc), and the purpose of the component. The age of a component may signify use of outdated technology and may have a higher probability of being passed over by security researchers. Reliability engineers will also site a lower Mean Time to Failure (MTTF) and Mean Time Between Failures (MTBF) on older hardware components.

===== Outdated Components =====
Newer versions of components typically improve quality or performance in addition to providing new features. These improvements can be inherited by the applications that have a dependency on them. Components that are End-of-Life (EOL) or End-of-Support (EOS) also impact risk. Two common approaches to community supported open-source is:

* Support the latest revision of the last (x) releases - (i.e. 4.3.6 and 4.2.9)
* Support only the latest published version (i.e. 4.3.6 today and 4.4.0 tomorrow)

Depending on the risk appetite, it may be strategic to only use third-party and open source components that are supported.

With reference to the [https://semver.org/ Semantic Versioning] nomenclature, API changes can be expected between major versions of a component, but are rare between minor versions and patches. Changes in APIs can negatively impact an organizations ability to respond to emerging vulnerabilities. When a vulnerability is published affecting a wide range of versions but the fix is immediately available only in newer versions, changes in a components API may result in longer remediation times. Keeping components up-to-date can reduce remediation time when a rapid response is warranted.

Component analysis can identify outdated components as well as provide information about newer versions.

===== Known Vulnerabilities =====
Historically, known vulnerabilities referred to entries (CVEs) in the [https://nvd.nist.gov/ National Vulnerability Database] (NVD). The NVD describes (via [https://nvd.nist.gov/products/cpe CPE]) three types of components:
* Applications (includes libraries and frameworks)
* Operating Systems
* Hardware

While the NVD may be the most recognizable source of vulnerability intelligence, it's not the only. There are multiple public and commercial sources of vulnerability intelligence. Having a ''known'' vulnerability doesn't require the vulnerability information be present in one of these sources. Simply being documented (i.e. social media post, defect tracker, commit log, release notes, etc) classifies the vulnerability as being ''known''.

Component analysis will commonly identify known vulnerabilities from multiple sources of vulnerability intelligence.

===== Component Type =====
Frameworks and libraries have unique upgrade challenges and associated risk. Abstractions, coupling, and architectural design patterns may affect the risk of using a given component type. For example, logging libraries may be embedded throughout a large application, but replacing implementations can likely be automated. Likewise, replacing a web application framework for an alternative framework would likely be a high-risk endeavor leading to architectural changes, regressions, and code rewrites. Hardware components also come in both serviceable and non-serviceable varieties, each having varying degrees of risk. Evaluating the type should be part of every Component Analysis strategy.

===== Component Quantity =====
The number of third-party and open source components in a project should be evaluated. The cost of using open source can exponentially increase with every new component when there are hundreds or thousands of applications in a given environment. In addition to increased operational cost, a decrease in a development teams ability to maintain growing sets of components over time can be expected. This is especially true for teams with time-boxed constraints.

===== Repository Trust =====
Components in many software ecosystems are published and distributed to central repositories. Repositories have known threats. Some of the threats against public repositories include:

* Typosquatting - naming a component in such as way as to take advantage of common misspelling
* Organization/Group abuse - pretending to be a public person or entity and abusing the perceived trust
* Malware through transfer - leveraging weak or absent code-signing requirements to spread malware through the transfer of an open source project from one maintainer to another
* Cross Build Injection (XBI) - Abusing dependency resolution schemes and weak infrastructure controls to inject malicious components in place of safe ones

Public repositories that have code-signing and verification requirements have some level of trust, whereas public repositories without basic countermeasures do not. For no-trust or low-trust repositories, utilizing private repositories may be advantageous. Private repositories refer to repositories where access is limited, usually software that organizations install and control, or a commercially available service. ''Golden repositories'' containing vetted or whitelisted components are a common use-case for private repositories. Private repository services focusing on security may additionally provide anti-malware analysis and static source code analysis requirements prior to acceptance in the repository. When leveraging private repositories, it is important to have traceability to the components' repository of origin.

===== Pedigree =====
A component's pedigree refers to the traceability of all changes (i.e. commits), releases, modifications, packaging, and distribution across the entire supply chain. In physical supply chains this is referred to as the Chain of Custody. Obtaining a components pedigree may involve a mixture of automation across multiple systems and suppliers, along with legal and verifiable supporting documentation.

Verification and validation of component pedigree is typically reserved for applications with a low tolerance for risk.

===== License =====
Third-party and open-source software typically has one or more licenses assigned. The chosen license may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific actions if the component is modified. Component Analysis can identify the license(s) for a given component and may optionally provide guidance as to the nature of the license (i.e. copyright, copyleft, OSI approved, etc). Utilizing components with licenses which conflict with an organizations objectives or ability can create serious risk to the business.

=====Inherited Risk =====
Third-party and open source components often have dependencies on other components. A ''transitive dependency'' is when an application has a direct dependency on a component and that component has a dependency on another component. Transitive dependencies are common and are expected in highly modular ecosystems which values reuse over re-invent. Like any component, transitive dependencies have their own risk which is inherited by every component and application that relies on them. Components may additionally have specific runtime or environmental dependencies with implementation details not known or prescribed by the component. Component Analysis can aggregate the risk of all direct, transitive, runtime, and environmental dependencies providing a holistic view of inherited risk.

===== Project Health =====
There are many datapoints to consider when evaluating the health of an open source project.
* Quality Controls and Metrics - The overall quality and controls for achieving and maintaining high-quality components may be a factor in risk evaluation. For software components, this refers to the use of unit and integration tests, linters and static analysis tools, the percentage of coverage, and results from various tools.
* Community Engagement - The current and historical trend for a project and its maintainers to accept pull requests, answer defect and enhancement requests, and engage in productive collaboration with the community may be a factor in risk evaluation.
* Vulnerability Analysis - Analyzing current and historical security vulnerabilities for timeline trends and for root-cause patterns may signify a projects ability to protect the community from future (and similar) issues. This activity may be a factor in risk evaluation.

== Software Transparency ==
Multiple efforts between government and industry are attempting to define ''Software Transparency''. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of bill-of-materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency, designed to provide consumers with information they can use to evaluate risk prior to consumption. A BOM has the added advantage of being useful for component analysis throughout the entire lifecycle of the products use.

Some Software Transparency efforts are focusing on Software Bill-of-Materials (SBOM) while others are more inclusive of all supply chain components. The [https://www.fda.gov/ U.S. Food and Drug Administration] (FDA) defines Cyber Bill-of-Materials (CBOM) as:
<blockquote>''a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.''</blockquote>

There are multiple BOM standards including [https://cyclonedx.org/ CycloneDX], [https://spdx.org/ SPDX], and [https://www.iso.org/standard/65666.html SWID], each having their own strengths and use-cases they were designed to solve. Evaluating BOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

== Component Identification ==
Component ecosystems generally devise different terminology and formats for representing components. This self-imposed fragmentation makes uniquely identifying and representing components difficult when referring to them outside of their respective ecosystems. Centralized databases such as the [https://nvd.nist.gov/products/cpe CPE Product Dictionary] maintained by [https://www.nist.gov/ NIST] adds additional fragmentation as the CPE vendor and product names often do not reflect reality.

Generally, a component will have a name and version. Components may optionally have a higher-level grouping identifier, commonly referred to as a groupId, organization, or vendor. When referencing components in a C-SCRM framework it is important to have a standard and uniform way to represent them. The [https://github.com/package-url Package URL] [https://github.com/package-url/purl-spec specification] provides a decentralized and uniform way to represent components.

<pre>
scheme:type/namespace/name@version?qualifiers#subpath
</pre>
For example:
<pre>
pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
pkg:gem/jruby-launcher@1.1.2?platform=java
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/%40angular/animation@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25
</pre>

== Open Source Policy ==
Open source policies provide guidance and governance to organizations looking to reduce third-party and open source risk. Policies typically include:
* Restrictions on component age
* Restrictions on outdated and EOL/EOS components
* Prohibition of components with known vulnerabilities
* Restrictions on public repository usage
* Restrictions on acceptable licenses
* Component update requirements
* Blacklist of prohibited components and versions
* Acceptable community contribution guidelines

While the open source policy is usually filled with restrictions, it provides an organizations security, development, and legal teams an opportunity to create solutions for healthy open source usage.

== Recommendations ==
* Limit the age of acceptable components to three years or less with exceptions being made for high-value, single purpose components that are still relevant
* Prohibit the use of end-of-life (EOL) components
* Prohibit the use of components with known vulnerabilities. Update components that are exploitable with high to moderate risk first.
* Reduce the attack surface by excluding unnecessary direct and transitive dependencies
* Reduce the number of suppliers and use the highest quality components from those suppliers
* Establish a maximum level of acceptable risk for public repositories. Utilize private repositories in lieu of untrusted ones.
* Automate component updates (from trusted repositories only)
* Provide time-boxed allowances every sprint to maintain component hygiene
* Establish a whitelist of acceptable licenses, a blacklist of prohibited licenses, and seek advice from counsel for all other licenses
* Automate the creation of bill-of-materials (BOM) for all deliverables (hardware and software)
* Contractually require BOMs from vendors and embed their acquisition in the procurement process
* Automate the analysis of all third-party and open source components during Continuous Integration (CI), either by analyzing the files themselves, or by analyzing a BOM
* Import BOMs into systems capable of tracking, analyzing, and proactively monitoring all components used by every asset in an environment (i.e. enterprise wide, entire cloud infrastructure, etc)

== Tools Listing ==

{{:Template:OWASP Tool Headings}}
{{OWASP Tool Info || tool_name = [https://www.blackducksoftware.com/ Black Duck Hub] || tool_owner = Synopsys || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.nexb.com/ DejaCode] || tool_owner = nexB || tool_licence = Commercial || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Check|Dependency-Check]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [[OWASP Dependency Track Project|Dependency-Track]] || tool_owner = OWASP || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://dependabot.com/ Dependabot] || tool_owner = Dependabot || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://depshield.github.io DepShield] || tool_owner = Sonatype || tool_licence = Open Source || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/RetireNet/dotnet-retire DotNET Retire] || tool_owner = Retire.NET Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.flexera.com/products/software-composition-analysis/flexnet-code-insight.html FlexNet Code Insight] || tool_owner = Flexera || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.fossology.org/ FOSSology] || tool_owner = Linux Foundation || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://libraries.io/ Libraries.io ] || tool_owner = Tidelift || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.npmjs.com/ NPM Audit] || tool_owner = NPM || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://github.com/sensiolabs/security-checker PHP Security Checker] || tool_owner = SensioLabs || tool_licence = Open Source || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://snyk.io/ Snyk] || tool_owner = Snyk || tool_licence = Commercial / Freemium || tool_platforms = SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sourceclear.com/ SourceClear] || tool_owner = Veracode || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://www.sonatype.com/ Nexus IQ] || tool_owner = Sonatype || tool_licence = Commercial || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://www.whitesourcesoftware.com/ Open Source Lifecycle Management] || tool_owner = WhiteSource Software || tool_licence = Commercial || tool_platforms = Cross Platform / SaaS}}
{{OWASP Tool Info || tool_name = [https://retirejs.github.io/retire.js/ Retire.js] || tool_owner = RetireJS Project || tool_licence = Open Source || tool_platforms = Cross Platform}}
{{OWASP Tool Info || tool_name = [https://vulndb.cyberriskanalytics.com/ VulnDB] || tool_owner = Risk Based Security || tool_licence = Commercial || tool_platforms = SaaS}}
|}

== References ==

* https://csrc.nist.gov/projects/supply-chain-risk-management - Cyber Supply Chain Risk Management (C-SCRM)
*http://stwww-production.herokuapp.com/calculator/ - Impact of software supply chain practices: Development Waste (Sonatype)
*https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM623529.pdf - Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (FDA)
*https://cyclonedx.org/ - CycloneDX specification
*https://spdx.org/ - Software Package Data Exchange (SPDX)
* https://www.iso.org/standard/65666.html - SWID (ISO/IEC 19770-2:2015)
*https://github.com/package-url - Package URL specification and reference implementations
*https://cdn2.hubspot.net/hub/203759/file-1100864196-pdf/docs/Contrast_-_Insecure_Libraries_2014.pdf - The Unfortunate Reality of Insecure Libraries (Contrast Security)
*https://safecode.org/wp-content/uploads/2014/06/SAFECode_Supply_Chain0709.pdf - Framework for Software Supply Chain Integrity (SAFECode)
*https://safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf - Managing Security Risks Inherent in the Use of Third-party Components (SAFECode)
*https://www.mitre.org/sites/default/files/publications/pr-18-2417-deliver-uncompromised-MITRE-study-8AUG2018.pdf - Deliver Uncompromised (MITRE)

[[Category:OWASP_Tools_Project]]
[[Category:OWASP_Best_Practices]]

OWASP Tool Info

2019-01-03T07:26:31Z

Steve Springett: added optional description column

<includeonly>
{| border="1"
|-
|colspan="2" align="left" | {{#if: {{{tool_name|}}} | {{{tool_name}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_owner|}}} | {{{tool_owner}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_website|}}} | {{{tool_website}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_licence|}}} | {{{tool_licence}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_stable_release|}}} | {{{tool_stable_release}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_release_date|}}} | {{{tool_release_date}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_platforms|}}} | {{{tool_platforms}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_technologies|}}} | {{{tool_technologies}}} | N/A }}
|colspan="2" align="left" | {{#if: {{{tool_description|}}} | {{{tool_description}}} | N/A }}
|-
|}</incldueonly>
<noinclude>
Tool information template.
</noinclude>

OWASP Dependency Track Project

2018-12-25T04:22:51Z

Steve Springett: /* News and Events */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://plugins.jenkins.io/dependency-track Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [22 Dec 2018] v3.4.0 Released
* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

File:Integrations.png

2018-12-10T00:48:37Z

Steve Springett: Steve Springett uploaded a new version of File:Integrations.png

Dependency-Track Ecosystem and Integrations

OWASP Dependency Track Project

2018-11-16T15:03:20Z

Steve Springett: Jenkins plugin URL change

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://plugins.jenkins.io/dependency-track Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2018-11-14T03:01:13Z

Steve Springett: 3.3.1 released

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [13 Nov 2018] v3.3.1 Released
* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2018-10-25T19:05:38Z

Steve Springett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [25 Oct 2018] v3.3.0 Released
* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

Projects/OWASP Dependency Track Project/Roadmap

2018-10-19T15:46:46Z

Steve Springett:

Dependency-Track utilizes GitHub milestones for roadmap and backlog tracking. Refer to https://github.com/DependencyTrack/dependency-track

OWASP Dependency Track Project

2018-10-19T15:41:32Z

Steve Springett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects|Flagship Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]
[[Category:Flagship Projects]]

OWASP Dependency Track Project

2018-10-19T15:23:06Z

Steve Springett:

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:300px;" |
[[File:Dependency-Track-logo-300x100.png|250px|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="200" cellpadding="2"
|-
| align="center" valign="top" width="50%" | [[File:Mature_projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages|Mature Project]]
| align="center" valign="middle" width="50%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" valign="top" width="100%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]

OWASP Dependency Track Project

2018-10-19T07:21:53Z

Steve Springett: /* OWASP Dependency-Track */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:400px;" |
[[File:Dependency-Track-logo-300x100.png|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="400" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="33%" | [[File:Mature_projects.png|130px|link=https://www.owasp.org/index.php/OWASP_Project_Stages|Mature Project]]
| align="center" valign="top" width="33%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
| align="center" valign="top" width="33%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]

OWASP Dependency Track Project

2018-10-19T07:15:36Z

Steve Springett: /* Classifications */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless|700x700px]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:400px;" |
[[File:Dependency-Track-logo-300x100.png|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="400" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="33%" | [[File:Mature_projects.png|130px|link=https://www.owasp.org/index.php/OWASP_Project_Stages|Mature Project]]
| align="center" valign="top" width="33%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
| align="center" valign="top" width="33%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]

OWASP Dependency Track Project

2018-10-18T02:17:03Z

Steve Springett: /* Main */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

[[File:Integrations.png|frameless|700x700px]]

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:400px;" |
[[File:Dependency-Track-logo-300x100.png|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="400" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="33%" | [[File:Midlevel_projects.png|130px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Lab_Projects|Lab Project]]
| align="center" valign="top" width="33%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
| align="center" valign="top" width="33%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]

File:Integrations.png

2018-10-18T02:14:15Z

Steve Springett:

Dependency-Track Ecosystem and Integrations

OWASP Dependency Track Project

2018-10-18T02:08:53Z

Steve Springett: banner change

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:400px;" |
[[File:Dependency-Track-logo-300x100.png|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="400" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="33%" | [[File:Midlevel_projects.png|130px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Lab_Projects|Lab Project]]
| align="center" valign="top" width="33%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
| align="center" valign="top" width="33%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]

OWASP Dependency Track Project

2018-10-03T14:18:00Z

Steve Springett: /* News and Events */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: lab_big.jpg|link=OWASP_Project_Stages#tab.3DLab_Projects]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP Dependency-Track==

Modern applications leverage the availability of existing components for use as building blocks in application development. By using existing components, organizations can dramatically decrease time-to-market. Reusing existing components however, comes at a cost. Organizations that build on top of existing components assume risk for software they did not create. Vulnerabilities in third-party components are inherited by all applications that use those components. The [[OWASP Top Ten]] (2013 and 2017) both recognize the risk of [[Top 10 2013-A9-Using Components with Known Vulnerabilities|using components with known vulnerabilities]].

Dependency-Track is a Software Composition Analysis (SCA) platform that keeps track of all third-party components used in all the applications an organization creates or consumes. It integrates with multiple vulnerability databases including the [https://nvd.nist.gov/ National Vulnerability Database] (NVD), [https://www.npmjs.com/advisories NPM Public Advisories], [https://ossindex.sonatype.org/ Sonatype OSS Index], and [https://vulndb.cyberriskanalytics.com VulnDB] from [https://www.riskbasedsecurity.com Risk Based Security]. Dependency-Track monitors all applications in its portfolio in order to proactively identify vulnerabilities in components that are placing your applications at risk. Use of Dependency-Track can play a vital role in an overall [https://csrc.nist.gov/Projects/Supply-Chain-Risk-Management Cyber Supply Chain Risk Management] (C-SCRM) program by fulfilling many of the recommendations laid out by [https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf SAFECode].

Dependency-Track is designed to be used in an automated DevOps environment where BoM (bill-of-material) formats are automatically ingested during CI/CD. Use of the [https://wiki.jenkins.io/display/JENKINS/OWASP+Dependency-Track+Plugin Dependency-Track Jenkins Plugin] is highly recommended for this purpose and is well suited for use in Jenkins Pipeline. In such an environment, Dependency-Track enables your DevOps teams to accelerate while still keeping tabs on component usage and any inherited risk.

Dependency-Track can also be used to monitor vulnerabilities in COTS (commercial off-the-shelf) software.

==Features==
* Increases visibility into the use of vulnerable and outdated components
* Flexible data model supporting an unlimited number of projects and components
* Tracks vulnerabilities and inherited risk
** by component
** by project
** across entire portfolio
* Tracks usage of out-of-date components
* Includes a comprehensive auditing workflow for triaging results
* Configurable notifications supporting Slack, Microsoft Teams, Webhooks, and Email
* Supports standardized SPDX license ID’s and tracks license use by component
* Supports [http://cyclonedx.org CycloneDX] and [https://spdx.org/ SPDX] bill-of-material formats and Dependency-Check XML
* Easy to read metrics for components, projects, and portfolio
* Provides a reliable mirror of the NVD data feed
* API-first design facilitates easy integration with other systems
* API documentation available in Swagger 2.0 (OpenAPI 3 support coming soon)
* Supports internally managed users, Active Directory/LDAP, and API Keys
* Simple to install and configure. Get up and running in just a few minutes

==Distributions==
Dependency-Track supports the following three deployment options:

* Executable WAR
* Conventional WAR
* Docker container

==Licensing==
OWASP Dependency-Track is licensed under the [https://www.apache.org/licenses/LICENSE-2.0 Apache 2.0 license].

| valign="top" style="padding-left:25px;width:400px;" |
[[File:Dependency-Track-logo-300x100.png|link=File:Dependency-Track-logo-large.png]]
== Quick Download ==

Ready-to-deploy distributions are available from the Dependency-Track website
* [https://dependencytrack.org/ Website]
* [https://github.com/DependencyTrack Source Code]

== News and Events ==

* [02 Oct 2018] v3.2.2 Released
* [21 Sep 2018] v3.2.1 Released
* [06 Sep 2018] v3.2.0 Released
* [19 Jun 2018] v3.1.0 Released
* [02 May 2018] v3.0.4 Released
* [13 Apr 2018] v3.0.3 Released
* [30 Mar 2018] v3.0.2 Released
* [27 Mar 2018] v3.0.1 Released
* [26 Mar 2018] v3.0.0 Released
* [08 Oct 2017] v3.0 [https://groups.google.com/forum/#!topic/dependency-track/0PUJI5rNgzI Updates to community]
* [16 Jun 2017] [https://www.youtube.com/watch?v=88YAlzuDH04&t=50s Presentation at OWASP Summit 2017]
* [10 Dec 2016] Work begins on v3.0

== Media ==

[https://www.youtube.com/channel/UC8xdttysl3gNAQYvk1J9Efg OWASP Dependency-Track Channel (YouTube)]

[https://www.appsecpodcast.org/2018/04/12/dependency-check-and-dependency-track-s03e13/ AppSec Podcast (S03E13)]

== Documentation ==

[https://docs.dependencytrack.org Dependency-Track Documentation]

== Project Leader ==

[[User:Steve_Springett|Steve Springett]]

== Related Projects ==

* [[OWASP_Dependency_Check|OWASP Dependency-Check]]

==Classifications==

{| width="400" cellpadding="2"
|-
| rowspan="2" align="center" valign="top" width="33%" | [[File:Midlevel_projects.png|130px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Lab_Projects|Lab Project]]
| align="center" valign="top" width="33%" | [[File:Owasp-builders-small.png|link=Builders]] [[File:Owasp-defenders-small.png|link=Defenders]]
| align="center" valign="top" width="33%" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|}

|}

=Screenshots=

<gallery widths="300px">
File:Dependency-Track_Screenshot-_Dashboard.png|Dashboard
File:Dependency-Track_Screenshot_-_Projects.png|Projects
File:Dependency-Track_Screenshot_-_Vulnerable_Component.png|Vulnerable Component
File:Dependency-Track_Screenshot_-_Vulnerability.png|Vulnerability

</gallery>

= Acknowledgements =
This project would not be possible without the existence of the [[OWASP_Dependency_Check]] project. Special thanks to Jeremy Long and the Dependency-Check core team for their hard work.

==Dependency-Track Core Team==
* [[User:Steve_Springett|Steve Springett]]

==Sponsors==

Dependency-Track is created by a worldwide group of volunteers who have dedicated their time, talent, or provided financial support to the project.

The project would like to acknowledge and thank the following organizations that have helped move this project forward

* [https://www.riskbasedsecurity.com/ Risk Based Security]

OWASP Dependency-Track is an open source project, created by people who believe that the knowledge of using vulnerable components should be accessible to anyone with a desire to know. By supporting this project, you'll allow the team to outsource testing, infrastructure, further research and development efforts, and engage in outreach to various communities that would benefit from this technology.

{{#widget:PayPal Donation
|target=_blank
|budget=OWASP Dependency-Track
}}

= Road Map =
Dependency-Track uses [https://github.com/DependencyTrack/dependency-track/milestones GitHub milestones] to track roadmaps and future releases.

=Community=
Feedback from the community is always encouraged. Tell us what you like, what needs to be improved, and what features would be beneficial to your organization.

Three ways to get involved:
* [https://github.com/DependencyTrack/dependency-track/issues GitHub Issues] - Collaborate on open issues
* [https://gitter.im/dependency-track/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge Gitter] - Chatroom built around GitHub
* [https://owasp.slack.com/messages/proj-dependency-track Slack] - The Dependency-Track Slack channel

Pull requests are highly encouraged. No contribution is too small. Do you know how to create test cases? Help us out. Want to write (or correct) some docs? Yes please... All contributions are appreciated.

=Project About=
{{:Projects/OWASP_Dependency_Track_Project | Project About}}

__NOTOC__ <headertabs />

[[Category:OWASP Project]]
[[Category:OWASP_Builders]]
[[Category:OWASP_Defenders]]
[[Category:OWASP Tool]]