In the previous chapters we have already given some hints that enable a safer operation. Here we want to summarise and expand the individual elements. In doing so, we will be guided by the OpenSSF Scorecard. Alternatively, you can also follow ISO/IEC 5230/OpenChain.
This check determines whether the project has open, unfixed vulnerabilities in its own code base or in its dependencies. An open vulnerability can be easily exploited and should be closed as soon as possible.
If a vulnerability is found in a dependency, you should update to a non-vulnerable version; if no update is available, you should consider removing the dependency.
If you believe that the vulnerability does not affect your project, an
osv-scanner.toml file can be created for
osv, including the ID to
ignore and a reason, for example:
[[IgnoredVulns]] id = "GO-2022-1059" # ignoreUntil = 2022-11-09 # Optional exception expiry date reason = "No external http servers are written in Go lang."
Are the dependencies updated automatically?#
Outdated dependencies make a project vulnerable to attacks on known vulnerabilities. Therefore, the process of updating dependencies should be automated by checking for outdated or insecure requirements and updating them if necessary. You can use dependabot or PyUp for this purpose.
Are the dependencies still maintained?#
This indicates possible unpatched security vulnerabilities. Therefore, it should be checked regularly whether a project has been archived. Conversely, the OSSF scorecard assumes that with at least one commit a week for 90 days, the project is very actively maintained. However, a lack of active maintenance is not necessarily always a problem: smaller utilities in particular usually do not need to be maintained, or only very rarely. So a lack of active maintenance only tells you that you should investigate the situation more closely.
You can also display the activities of a project with badges, for example:
Is there a safety concept for the project?#
SECURITY.md or similar file should have been published with
the project. This file should contain information
how a security vulnerability can be reported without it becoming publicly visible,
on the procedure and schedule for disclosing the vulnerability,
to links, for example URLs and emails, where support can be requested.
Does the project contain a usable licence?#
A license indicates how the source code may or may not be used. The absence of a licence complicates any kind of security review or audit and poses a legal risk for potential use.
OSSF-Scorecard uses the GitHub License API
for projects hosted on GitHub, otherwise it uses its own heuristics to detect a
published license file. Files in a
LICENSES directory should be named
with their SPDX licence identifier followed
by an appropriate file extension as described in the REUSE
Are the best practices of the CII being followed?#
The Core Infrastructure Initiative (CII) Best Practices Program includes a set of security-oriented best practices for open source software development:
the vulnerability reporting procedure is published on the project page
a working build system automatically rebuilds the software from source code
a general policy that tests are added to an automated test suite when important new features are added
various cryptography criteria are met, if applicable
at least one static code analysis tool applied to each planned major production release
You can also get a corresponding badge with the OpenSSF Best Practices Badge Programm.
Are CI tests carried out in the project?#
Before code is merged into pull or merge requests, tests should be performed to help detect errors early and reduce the number of vulnerabilities in a project.
Does the project use fuzzing tools?#
Fuzzing or fuzz testing passes unexpected or random data to your programme to detect bugs. Regular fuzzing is important to detect vulnerabilities that can be exploited by others, especially since fuzzing can also be used in an attack to find the same vulnerabilities.
Does your project use static code analysis tools?#
Static code analysis tests the source code before the application is executed. This can prevent known bug classes from being accidentally introduced into the codebase.
To check for vulnerabilities, you can use bandit, which you can also integrate into your
repos: - repo: https://github.com/PyCQA/bandit rev: '1.7.5' hooks: - id: bandit
Risk assessment of the source code#
Is the project free of checked-in binaries?#
Generated executables in the source code repository (for example Java
.class files, Python
.pyc files) increase risk because they are
difficult to verify, so they may be out of date or maliciously tampered with.
These problems can be countered with verified, reproducible builds, but their
executables should not end up back in the source code repository.
Is the development process vulnerable to the introduction of malicious code?#
With protected Git branches <protected_branches>, rules can be defined for the adoption of changes in standard and release branches, for example automated static code analyses with flake8, Pysa, Wily and code reviews via merge requests.
Are code reviews performed?#
Code reviews can detect unintentional vulnerabilities or possible introduction of malicious code. Possible attacks can be detected in which the account of a team member has been infiltrated.
Does the project involve people from several organisations?#
This is taken as an indication of a lower number of trustworthy code reviewers. For this purpose, you can search for different entries in the * Company* field in the profiles. At least three different companies in the last 30 commits are desirable, whereby each of these team members should have made at least five commits.
Risk assessment of the builds#
Are dependencies declared and fixed in the project?#
In your project, dependencies used during the build and release process should be pinned. A pinned dependency should be explicitly set to a specific hash and not just to a mutable version or version range.
This can reduce the following security risks:
Testing and deployment are done with the same software, which reduces deployment risks, simplifies debugging and enables reproducibility.
Compromised dependencies do not undermine the security of the project.
Substitution attacks, i.e. attacks that aim to confuse dependencies, can thus be countered.
However, fixing dependencies should not prevent software updates. You can reduce this risk by
automated tools that notify you when dependencies in your project are out of date
update applications that lock dependencies quickly.