tasks: Improving research software security

How do you improve the security of your research software?

This page explains how you can understand, prioritise, and implement security practices in your research software to protect data, results, and collaborators.

Description

Research software security is about protecting your code, data, systems, and users from unauthorised access, tampering, disruption, or misuse. Weak security can compromise research integrity, expose sensitive data, and undermine reproducibility. Because research software often depends on open-source components and distributed collaboration, it is particularly exposed to risks such as supply chain attacks, vulnerable dependencies, and credential leaks.

Considerations

• Your software needs to protect confidentiality, integrity, and availability of data, results, and services.
• You should treat security as part of software quality, not as a separate activity that happens only before release.
• Research software is often developed under time pressure, which can lead to security being added late rather than designed in from the start.
• Your dependencies are part of your security boundary, because third-party packages can introduce known vulnerabilities or supply chain risks.
• Your repository configuration matters as much as your code, because branch protection, review requirements, CI checks, token permissions, and signed releases affect how easily code or artefacts can be tampered with.
• Your credentials need special handling, because secrets committed to a repository may remain exposed through Git history, forks, clones, or cached copies even after the file is changed.
• Security tools can find common problems, but they do not prove that your software is secure.
• AI-generated code, copied snippets, and generated configuration should receive the same review, testing, and security checks as code written manually.
• Security involves trade-offs between openness, usability, collaboration, and protection, especially when your project handles sensitive data or supports external users.

Solutions

• Start with a lightweight security baseline for your repository. Use OpenSSF Scorecard to assess repository-level security risks and identify which practices to improve first. OpenSSF Scorecard can help you evaluate your own repository or dependencies you may want to reuse. Relevant checks include branch protection, code review, CI tests, dependency update tooling, pinned dependencies, signed releases, token permissions, binary artefacts, and security policies.

• Detect exposed secrets before they become incidents. Use gitleaks to scan repositories, files, and standard input for passwords, API keys, tokens, and other secrets. If your project is hosted on GitHub, enable GitHub secret scanning to detect hardcoded credentials across repository history and related GitHub content. If a secret has already been committed, revoke or rotate it rather than relying only on deleting it from Git history.

gitleaks detect --source .

• Check your source code for security issues. Use Bandit for Python projects to find common security issues by scanning Python files and reporting findings. Bandit supports recursive scanning, configuration files, severity and confidence filters, baselines, and machine-readable output formats. For multi-language projects, use SonarQube or another static analysis tool that fits your language stack. Treat static analysis findings as review prompts: confirm whether each finding is relevant, fix real issues, document accepted risks, and tune noisy rules over time.

bandit -r src/

• Scan dependencies for known vulnerabilities. Use OWASP Dependency-Check to identify project dependencies and check whether they contain publicly disclosed vulnerabilities. Dependency-Check provides command line, build tool, and CI/CD integrations. If your project uses GitLab, use GitLab dependency scanning through GitLab CI/CD to identify known vulnerabilities in runtime, development, and transitive dependencies.

dependency-check --project "my-project" --scan .

• Keep dependencies up to date automatically. Use Dependabot or Renovatebot to open update pull requests when dependencies, build tools, or GitHub Actions need updating. Treat automated dependency updates as review prompts rather than automatic approvals. Combine dependency update tools with tests and vulnerability scanning so that updates are checked before they are merged.

• Run security checks in CI/CD rather than relying on local discipline. Use GitHub Actions or GitLab CI/CD to run secret scanning, static analysis, dependency scanning, and tests automatically on pull requests. For GitHub projects, combine CI with tools such as gitleaks, Bandit, OWASP Dependency-Check, and OpenSSF Scorecard. For GitLab projects, use GitLab CI/CD with dependency scanning and project-specific security jobs.

name: security-checks

on:
  pull_request:
  push:
    branches: [main]

jobs:
  python-security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Bandit
        run: |
          pip install bandit
          bandit -r src/
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2

• Use repository controls to reduce supply chain risk. Enable branch protection, require code review, require passing CI checks, and restrict workflow token permissions so that automation runs with least privilege. These controls make it harder for accidental changes, compromised accounts, or unsafe automation to alter your default branch or release process unnoticed. The Scorecard baseline described above already surfaces which of these controls are missing, so use it to track them rather than auditing each one by hand.

• Use signed releases when users depend on your published artefacts. Signed releases help downstream users verify that release artefacts have not been tampered with. Consider this especially when users install your software from release archives, package registries, containers, or workflow registries. A common route is to sign artefacts with Sigstore and its Cosign command-line tool, which supports keyless signing from CI so you do not have to manage long-lived signing keys. Signing your releases also satisfies the OpenSSF Scorecard signed-releases check.

• Choose security tools that match your project language and risk profile. For Python, start with Bandit, Pytest, gitleaks, and OWASP Dependency-Check. For Java, combine Maven, OWASP Dependency-Check, SonarQube, and CI-based tests. For C and C++, combine CMake, ctest, compiler warnings, static analysis, and dependency review. For GitHub-hosted projects, add OpenSSF Scorecard to assess repository-level supply chain practices. Verify tool recommendations against the current documentation before adopting them, because security tooling and platform features change quickly.

• Document your security expectations. Add a SECURITY.md file explaining how people should report vulnerabilities, which versions are supported, and what information is useful in a report. Back this up with a private reporting channel so that a finder is not left choosing between a public issue and saying nothing: on GitHub, enable private vulnerability reporting so anyone can submit a report from your repository’s Security tab, and you can triage and patch it privately before disclosure. GitLab has no direct equivalent, so name a security contact in your SECURITY.md or ask reporters to open a confidential issue, which only project members can see. If your software handles sensitive data, clinical data, personal data, credentials, or externally exposed services, involve institutional security, data governance, or information governance colleagues early. Make security decisions visible in your documentation so that contributors understand what is expected and users understand the level of care applied.

• Do not treat tools as a substitute for security judgement. Automated tools find common problems, but they do not replace threat modelling, design review, code review, testing, or incident response planning. Review findings regularly, fix issues that matter, document accepted risks, and revisit your choices when the software gains users, handles more sensitive data, or becomes part of a wider workflow.

Further Reading

• OWASP Top 10:2025 — This is the current edition of OWASP’s consensus list of the most critical risks in web applications, drawn from contributed vulnerability data and a practitioner survey. It gives you a shared vocabulary for talking about risk with collaborators and reviewers, and it is especially relevant to research software because supply chain failures now appear as a top-three category in their own right.

• OWASP Cheat Sheet Series — This is an actively maintained collection of concise, practical articles on specific application security topics, written and curated by the OWASP community. It is useful when you want concrete, task-focused guidance on areas such as input validation, authentication, authorisation, cryptographic storage, and secrets management, with each cheat sheet giving actionable recommendations you can apply directly.

• OWASP Developer Guide — This guide introduces software security concepts for developers and points to deeper OWASP resources. It is a good starting point when you need an accessible map of application security principles, secure development practices, verification, operations, and security culture.

• OWASP API Security Top 10 — This is OWASP’s companion list for APIs, covering risks such as object-level authorisation failures, unrestricted resource consumption, and unsafe consumption of third-party APIs. It is worth reading if your software exposes a web API, a service endpoint, or a data submission interface, because these risks are largely distinct from those in the general Top 10; the 2023 edition is the most recent at the time of writing.

• NIST Secure Software Development Framework — The SSDF provides a structured set of secure software development practices for reducing vulnerabilities and improving communication about secure development. It is most useful when you need a framework for planning, assessing, or explaining security practices across a project or organisation.

• OpenSSF Scorecard — OpenSSF Scorecard provides automated checks for repository-level security practices in open source projects. It is useful for assessing your own project baseline and for reviewing the security posture of dependencies you may want to reuse.

• Evaluating Software Supply Chain Security in Research Software — This paper examines supply chain security in research software repositories and highlights the relevance of practices such as signed releases and branch protection. It is especially relevant if you want research-software-specific evidence for why repository and dependency security matter.

AI Disclosure

This work was produced with the assistance of M365 Copilot based on GPT-5 reasoning model, Claude Opus 4.8 was subsequently used to check and modify the output. Claude Opus 5 was later used to verify sources and extend the page. Strict editorial control and factual verification was performed by the human author.

Related pages

tasks

Performing a code review

How do you review code?

tasks

Testing software

How to test your software?

tasks

Continuous Integration and Continuous Delivery/Deployment

How can you use CI/CD in software development?

tasks

Maintaining research software

Guidance on keeping research software functioning, understandable, and usable over time — covering ongoing maintenance practices, dependency management, documentation, versioning, and the management of technical debt.

tasks

Software Management Planning

How to prepare a software management plan?

Training

Tools and resources on this page

Shoaib Sufi

Editor

Shoaib Sufi

The University of Manchester / Software Sustainability Institute

GitHub Orcid

Shoaib Sufi, "Improving research software security". everse.software. http://everse.software/RSQKit/research_software_security .