Security¶

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.

Check vulnerabilities¶

Risk: High

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.

For such a check, you can use for example safety. Alternatively, you can use osv or pip-audit, which uses the Open Source Vulnerability Database.

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."

Maintenance¶

Are the dependencies updated automatically?¶

Risk: High

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 Safety CLI for this purpose.

You can also update your uv environments automatically.

Are the dependencies still maintained?¶

Risk: High

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?¶

Risk: Medium

Ideally, a 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?¶

Risk: Low

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 specification.

Are the best practices of the OpenSSF being followed?¶

Risk: Low

The Open Source Security Foundation (OpenSSF) 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 Program.

Continuous testing¶

Are CI tests carried out in the project?¶

Risk: Low

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?¶

risk: Medium

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 fuzzing?
Is the name of the repository included in the OSS fuzz project list?
Is ClusterFuzzLite used in the repository?
Are custom language-specific fuzzing features present in the repository, for example with atheris or OneFuzz?

Does your project use static code analysis tools?¶

Risk: Medium

Static code analysis tests the source code before the application is executed. This can prevent known bug classes from being accidentally introduced into the code base.

To check for vulnerabilities, you can use bandit, which you can also integrate into your .pre-commit-hooks.yaml:

repos:
- repo: https://github.com/PyCQA/bandit
  rev: '1.7.5'
  hooks:
  - id: bandit

You can also use Pysa for taint analyses.

For GitHub repositories you can also use CodeQL; see codeql-action.

Risk assessment of the source code¶

Is the project free of checked-in binaries?¶

Risk: High

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?¶

Risk: High

With protected Git 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?¶

Risk: High

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?¶

Risk: Low

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?¶

Risk: Medium

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.

Spack writes these hashes for the respective environment in spack.lock, uv in uv.lock file.

Tip

Üblicherweise verwalte ich diese Dateien jedoch nur bei Apps in Manage code with Git. Bei Libraries schränke ich üblicherweise lediglich den Versionsbereich der Abhängigkeiten in der pyproject.toml-Datei ein.

Spack writes these hashes for the respective environment in spack.lock, uv in uv.lock file. These files should therefore also be checked in with the source code.

This can reduce the following security risks for python-basics:apps:

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.