The process to objectively assess the security risk of 3rd party open source components or dependencies is outlined with consideration of the legacy way of performing the assessment, as well as the new process discussed within the project during the Hanoi development time frame.
Current Process
Someone researches the open source component that is desired, sometimes after the code has already been integrated into the EdgeX Project, without completion of any formal review.
The current high-level statistics are used in the manual research process (e.g. paper study) are:
Age: Age of the Open Source Project
Commits: Count - Total Commits
Issues: Count - Open Issues / Closed Issues
Releases: Count - Releases
Stars: Count - Stars
Forks: Count - Forks
Watchers: Count - Watchers
CVEs: Count - CVEs (query NVD database)
Other Criteria: Subjective Assessment of Reviewer
Ideal Process
The ideal process should take into consideration relevant data such as the project's age, popularity / maturity, evidence of security practices, recent commit history, diversity of committers, established CVE practices, or other observable evidence. In terms of licensing compliance, ideal process should also consider the license associated to the component as well.
Additionally, the ideal process should take into account the following scenarios:
- Existing Code (Skeletons in the Closet)
- Code in Holding (Analysis of code before it is accepted)
- Pull Request with new dependency
Developer Process for Each Use Case
| Use Case | Process | Tools | Applicability |
|---|---|---|---|
| 1.) Existing Code (Skeletons in the Closet) | Automated scan within build automation via Snyk CLI Scans of the published Docker images via Snyk with notifications to SIR Team members / Snyk Administrators | Snyk Community Bridge Advanced Snyk Reports Clair | Scan automation occurs within the build - PR merge to master |
| 2.) Code in Holding (Analysis of code before it is accepted) | Submitter adds a DepShield banner to the README Submitter includes scan findings from any of the recommended tools, for consideration as part of the code review Submitter should include scan results which include consideration of compliance (license) as well as security vulnerability (e.g. CVE) data Submitter should try to share the same relevant data as would be assessed within the context of a manual research process (e.g. paper study) so as to give the reviewers the complete view of what's being considered for inclusion within the project (e.g. dependency project's age, popularity / maturity, evidence of security practices, recent commit / release history, diversity of committers, established security reporting practices or evidence of a process for reporting / addressing findings within the open source community, and any other observable evidence) | At a bare minimum, project dependencies can be assessed via any of the following: | When considering code that is under consideration for moving into the main EdgeX Foundry Org, out of holding |
| 3.) Pull Request with new dependency | Submitter of a Pull Request (PR) will complete the Pull Request template to include any new changes that introduce dependency changes (e.g. imports or go module dependencies) The standard Pull Request template includes a question that asks - "Are there any new imports or modules? If so, what are they used for and why?" Submitter of the PR will add a If the dependency is security related, the submitter will add the Submitter should include scan results which include consideration of compliance (license) as well as security vulnerability (e.g. CVE) data, that can be reviewed by a Security WG member. | For a PR with new dependencies, the submitter of the PR will complete a manual paper study to collect the following data points for review:
| On a Pull Request, whenever there's a new dependency introduced as shown through changes to the go.mod |