On 17 May 2025, I received an email saying DataJourney was a finalist for the GitHub Secure Open Source Fund.
At the time, DataJourney was still growing. That made the central question even more useful:
How large should a project become before security is treated as a priority?
A year later, I do not think size is the deciding factor.
Small projects still use dependencies, accept contributions, handle credentials and run automated workflows. They may have fewer users, but they also have fewer people watching for problems.
For a small team, a security baseline matters more, not less.
From tools to habits
The GitHub Secure Open Source Fund combined funding with a focused security sprint, expert guidance and a full year of check-ins and community support. DataJourney was one of 71 projects included in GitHub’s early programme.
We started with practical foundations:
- CodeQL to surface vulnerabilities and errors
- Dependabot alerts to understand vulnerable dependencies
- Secret scanning to detect exposed credentials
- GitHub Actions to make checks repeatable
- A public security policy and vulnerability-reporting path
- CODEOWNERS to make responsibility visible
- A CycloneDX software bill of materials to understand what the project depends on
- OpenSSF Scorecard to examine the repository’s broader security posture
None of these tools finishes the work. Together, they create a baseline—a way for security to become part of the normal development path instead of something remembered after a problem.
The quiet risk inside our workflows
One of the most practical lessons came from GitHub Actions. We depend on workflows for much of the heavy lifting and for communicating with external tooling. Over time, I had let their permissions stay broad, mostly because the automation worked and its access was easy to overlook.
That was precisely why it mattered. A workflow that can read code, write to a repository, use secrets and talk to other services sits inside the project’s security boundary. If every job inherits broad access, a compromised action or a simple mistake has more room to travel.
We tightened the default GITHUB_TOKEN permissions and made access explicit at the workflow or job level, granting only what each task needed through GitHub’s permissions key. This follows GitHub’s least-privilege guidance for secure Actions use.
The change was small in YAML, but large in how we thought about automation. Actions was no longer plumbing around the product. It was production code with credentials.
The baseline matters more in the AI era
The pace of software creation is rising. GitHub’s 2025 Octoverse recorded nearly one billion commits, up 25% year over year, while new public repositories using an LLM SDK grew 178%.
AI can help a small team move faster, but review capacity does not automatically grow with the volume of code. In a 2025 evaluation of more than 100 models, Veracode found that 45% of generated code samples failed its security tests. That is not a prediction for every AI-assisted contribution, but it is a useful reminder: code that works is not automatically code we should trust.
Verification has to keep pace with generation. GitHub now runs automatic security validation for coding agents using CodeQL, dependency checks and secret scanning. This makes the work we began during the Fund even more important: security checks need to be routine enough to run whenever the code moves faster.
A year in progress
| Period | What changed |
|---|---|
| May 2025 | DataJourney became a finalist and was later selected for the Fund |
| June–July 2025 | Added CodeQL, OpenSSF Scorecard, a security policy and CycloneDX SBOM generation |
| September–November 2025 | Strengthened code ownership, vulnerability reporting, dependency review and incident-response planning |
| Early 2026 | Extended the same principles across more DataJourneyHQ projects and user-facing work |
| Mid 2026 | Began connecting code additions, quality findings and security alerts through shared dashboards |
| August 2026 | Completed the 12-month check-in after recording 50+ resolved findings in DataJourney and roughly 180 findings resolved or reviewed across DataJourneyHQ |
The biggest change was not the number of tools enabled or alerts closed. It was learning to ask better questions:
- What does this project depend on?
- Who owns the response when something goes wrong?
- Are risks increasing as the codebase grows?
- Can someone outside the engineering work understand where attention is needed?
- Will the next project inherit safer defaults, or start from zero again?
Visibility beyond the technical team
Security information often stays inside alerts, workflow files and reports that only a few people can understand. We wanted a more shared view.
Once findings become trends and dashboards, non-technical collaborators can participate too. They may not read a CodeQL query, but they can see whether findings are rising, what remains unresolved and where the team needs to slow down.
That visibility does not make everyone a security engineer. It gives more people enough context to ask useful questions and understand the health of what we are building.
For us, that is part of making security a habit across the wider ecosystem.
Passing it forward
The journey should not end with our own repositories.
Together with Cumbuca Dev, we have started turning our Secure Open Source Fund learning into practical training for maintainers and software teams.
The idea is simple: begin with one repository, understand its risks and leave with checks, settings, documentation, ownership and a security backlog the team can continue using.
Read about the GitHub Security Training for Software Teams
We want to give other maintainers a useful taste of the process without pretending every project needs a dedicated security department.
The 12-month programme is complete. The security work is not.
What we have now is a baseline and the confidence to keep improving it. The next experiment, repository or collaboration no longer has to begin from zero.
That may be the most useful outcome of the Fund.