A pull request that changes only a build workflow can still expose secrets, publish an artifact, or run commands on a maintainer-controlled runner. Treat workflow files, dependency manifests, release scripts, and repository settings as security-sensitive parts of an open source project, just like application code.
Public visibility does not make a contribution trustworthy. The goal is to protect maintainers and users without making legitimate contributions a chore. That takes limited access, changes people can review, automated checks, and a release process the team can repeat.
Map the paths into your project
List what contributors and dependencies can influence: pull requests, issue attachments, third-party actions or plugins, package updates, documentation that runs code examples, and scripts fetched during a build. Then identify which jobs can read secrets, write to the repository, upload artifacts, or publish packages. A failed test is inconvenient; a compromised publishing credential can affect everyone who installs the next release.
Keep the inventory short enough to update. Record who can merge and approve workflow changes, where release credentials live, and which automation has write access. Revisit it when you add a package registry, CI provider, or contributor role.
Protect accounts and repository controls
Require multifactor authentication for maintainers, especially those with release privileges. Give people only the access they need; an occasional reviewer rarely needs repository administration rights. Remove inactive accounts, revoke former maintainers' tokens, and prefer short-lived, narrowly scoped credentials where the platform supports them.
Protect the default branch with required reviews and passing checks. Give workflow and release configuration changes careful review. A CODEOWNERS file can route those changes to the right maintainers, but it cannot replace branch protection or a reviewer independent of the author. Apply equivalent rules to release branches and tags where supported.
Decide who may publish. If a maintainer can release directly from a workstation, passing pull-request checks cannot guarantee what was shipped. A protected publishing workflow should build from an approved commit or tag and use a credential limited to the relevant package.
Make contributions easy to inspect
A short CONTRIBUTING file should explain how to run tests, report security issues privately, and scope a pull request. When practical, ask contributors to separate dependency upgrades, generated files, and behavioral changes. A focused diff makes a surprising script command or new network request in a test easier to spot.
Review the whole change, not just the source file named in its description. Check manifest diffs, lockfiles, CI configuration, install scripts, and binary additions. A lockfile change should match the intended dependency update; an unexplained binary is hard to audit. If the project accepts generated code, document how to regenerate it and compare the result with the submitted files.
Handle security reports without exposing users
Add a SECURITY file or equivalent instructions naming supported versions and a private contact or reporting feature. Ask reporters not to post exploit details or sensitive data in a public issue before maintainers have assessed the problem. Acknowledge reports, reproduce them in an authorized test environment, prepare a fix, and coordinate disclosure and an advisory when appropriate. Don't promise a response deadline the volunteer team cannot meet.
Control dependency risk
Commit lockfiles for applications and tools when the ecosystem supports them, and use reproducible build settings. Pinned versions limit unexpected changes between builds, but a vulnerable version remains vulnerable. Use a tool such as Dependabot or Renovate to propose manageable updates, then test and review each change before merging.
Check direct and transitive dependencies for vulnerabilities and license issues. OSV-Scanner and package-manager audit commands can identify known advisories, but their findings need human assessment. Confirm that the affected package and version are present, whether your project can reach the vulnerable feature, and whether a fixed release exists. A scanner may miss an undisclosed vulnerability or flag code your project cannot exercise.
Keep runtime dependencies lean: a build-only formatter should not ship as a production dependency. Before adding a package, look at its maintenance history, requested permissions, install hooks, and the transitive code it brings in. If the project consumes external artifacts, verify checksums or signatures through an established trusted channel. A download URL alone is not proof of authenticity.
Run automation with limited authority
CI can test a contribution, but it should not give every job the same credentials. Code in an unknown contributor's pull request may run during compilation, testing, or package installation. Keep publishing secrets out of those jobs. Don't run untrusted pull-request code in a privileged workflow just to post a comment or label an issue.
Set workflow token permissions explicitly, with read-only access by default where possible. Grant write access only to jobs that need it, and keep testing separate from publishing. Restrict release triggers, require approval for protected environments where available, and use short-lived identity-based publishing instead of long-lived credentials when supported. Pin third-party CI actions to reviewed immutable revisions, with a plan to update those pins.
Use trusted, current runner images. A container does not necessarily protect credentials or mounted files from malicious build steps. If self-hosted runners handle outside contributions, consider their persistent state and network access. Ephemeral runners with tightly limited permissions reduce the chance that one job leaves changes behind for the next.
Choose tools that answer specific questions
A scanner helps most when someone owns its results and knows what to do with them. Start with checks that fit the project's language and build system:
- Secret scanning: Look for accidentally committed tokens and keys, including in pull requests. If you find a real secret, revoke or rotate it. Deleting the file alone will not remove it from history or logs.
- Static analysis: Use a language-aware tool such as CodeQL or Semgrep to find patterns worth reviewing. Tune its rules to the codebase and confirm findings rather than treating every alert as an exploitable flaw.
- Dependency auditing: Check for known advisories on a schedule and when manifests change. Record exceptions with an owner and a date to reassess them.
- Build and test checks: Require relevant unit tests and formatting or lint checks before merge. Add tests for fixed security bugs to catch the same behavior if it returns.
Try essential checks locally or in a low-privilege CI job before requiring them for merges. Constant false positives make a tool easy to ignore. Prioritize alerts by likely impact and exposure, not the count on a dashboard.
Make releases traceable
Before publishing, check that the version, commit, changelog, and built artifact agree. Build through a documented workflow, not an undocumented maintainer laptop. Keep enough information to identify the source commit and dependencies behind a release. A software bill of materials can help consumers identify included packages; it does not prove those packages are secure.
If the ecosystem supports artifact signing or provenance attestations, use them to help consumers verify origin. Know their limits: a signature links an artifact to a signing identity, not to a guarantee about the code's behavior. Protect signing and publishing authority as carefully as repository access.
After a suspected compromise, pause releases and revoke affected credentials. Inspect audit logs and workflow history, then compare published artifacts with expected builds. Communicate confirmed facts and affected versions rather than guessing at impact. A brief record of release steps and credential owners makes this work faster.
Start with a maintainable baseline
A small project can begin with protected merges, maintainer multifactor authentication, private vulnerability reporting, low-privilege CI, dependency updates, and a repeatable release path. Assign someone to review alerts and stale access monthly. For the next release, record the exact source commit in the release notes and check that the publishing job built that commit, not an unreviewed local checkout.
