neighbourhoodie-nnh-logo

NH:STA Special Episode with PHP posted Wednesday, March 18, 2026 by The Neighbourhoodie Team AnnouncementNewsInterviewSovereign Tech AgencyFOSS

Welcome to an omnibus edition of Neighbourhoodie’s Sovereign Tech Agency (STA) series. This post is part of our series on our work for the STA, formerly the Sovereign Tech Fund. Our introduction post explains why and how we are contributing to various Open Source projects.

In true special style, we’ll be covering a project that was part of season one, and to which we return to mark the beginning of our second season as the Tech Resilience implementation partner. It’s PHP! In this episode, we go over the automations we set up to support the project’s contributors and help keep PHP secure.

Introducing PHP

There’s a slim chance you haven’t heard the acronym “PHP”, and for good reason: it helps run more than 70% of the web, and has been doing so — while watching the rise and fall of technologies — for more than 30 years. Like the web itself, it’s changed significantly since its early days, and there’s never been a better time to get to know the elePHPant language. So let’s go!

Our Work

In 2021, the PHP Foundation was created to further the longevity and prosperity of PHP, including seeking sponsorships. When the Sovereign Tech Agency confirmed their support for the project, we were excited to get involved. We got to help the team with two separate efforts, which marked the finish of Season 1 of our work with the STA and the premiere of Season 2. Without more ado, let’s get to the interesting bits.

S01FIN

In its 30 ½ year lifespan, PHP had numerous people contribute to its infrastructure, the various services needed to run the open source project, covering everything from code collaboration, release engineering, documentation and project communication. Over time these services evolved organically with people contributing their pet project and then moving on. This left the (small but very capable) team in a situation where they had to wrangle a set of special-case servers and their setups instead of easily managing a more unified infrastructure setup. We managed to help them with much needed consolidation.

Automating Server Maintenance

First, we wanted to eliminate manual effort wherever possible. Together, we identified a solution to automate as much of the deployment process as feasible, and an access control mechanism that would give more maintainers granular access to server resources. This was also automated, so granting and revoking access is now much more convenient and would apply to all systems immediately. We also unified backup and restore procedures to a single solution across all services. By providing a unified and secure way to split the workload associated with infrastructure tasks and maintenance, the project can reduce over-reliance on a small team and bolster the strength of the project by making it easier for anyone to step in and help.

S02PRE

It’s an honour to work on a project so crucial to the modern web just once, but we got to do it twice! It seemed only fitting that we’d seize this opportunity to launch season two of our series on a very special note.

In our return to PHP, we contributed to another process aspect of the project that allows the team to securely distribute its packages: specifically, the safety of Windows binaries. This helps keep the project widely compatible, something known and loved about the project, but secure

To deliver PHP in a way that’s easier to get up and running on Windows operating systems, the project clones and optionally patches dependent libraries like OpenSSL, zlib and cUrl, and then bundles them into the Windows binaries. As downstream clones, they inherit all the security issues and vulnerabilities from the origin library, something the PHP team keeps a close — but manual — eye on. When a security update is released, project members will apply the necessary update to their clone and make it available as quickly as possible. Given the breadth of the open source ecosystem, staying informed of identified security issues, based on submitted Common Vulnerabilities and Exposures (CVEs), can be quite a load on the team.

Dependency Security Monitoring System

Once again, we were able to support the project by implementing automation measures to not only take a manual task off everyone’s hands (and minds!), but contribute to enhanced project security. Sound familiar? Yes, we were able to build upon extensive experience in this space.

In order to be comprehensive enough to effectively strengthen the project, our solution needed to:

  • regularly monitor new CVEs
  • keep a close eye on libraries PHP is dependent on
  • notify project members of the risk
  • create a single source for further discussion and action

First, we needed to get familiar with the project’s relevant infrastructure and upstream ecosystem using a list of the libraries the automation tool should monitor. We then wrote a bot to regularly run and check new CVEs against this list.

Building the Bot to Run on Continuous Integration (CI) Tooling

With requirements gathered, we could start thinking about the best way to build the bot. In a classic scenario, this would be the kind of thing you’d run on your own server and we had just helped streamline the PHP server infrastructure, so it would be easiest to just add another service there. Or would it? Running a service comes with many responsibilities and the service that is easiest to to run is one, very zen-like, one that you do not run at all. So instead we worked out with the team to find a clever way to have the bot run entirely in GitHub Actions, GitHub’s continuous integration (CI) service.

Of course, using something for a purpose other than what it was intended for requires what we all lovingly call workarounds. Instead of embracing the clean slate the Github Actions offers, our tool needed to remember which CVEs it already identified. Traditionally, this is where states and a database would come in, as a place to store records. To work around having a database, we needed to create something that remembered:

  • which CVEs it already checked for relevant
  • which relevant CVEs it had already found
  • which GitHub issues it had already created

In the event the bot turned up any new known risks or vulnerabilities added to the CVE database, the bot would open a GitHub ticket in the winlib repository as a means to notify the team, and prevent communication overhead and duplicate work.

Aside from the cost benefits of getting away without server infrastructure, it also adds a convenience factor that makes adoption easier, which is always a win when it comes to security-enhancing tools.

By the way, this is all portable to other projects as well. If you are in need of a robot that raises issues upon CVE releases of your C library dependencies, do feel free to adapt the bot code and/or get in touch. We’re always happy to help.

Next we hear from James Coglan, who authored the bot.

Reflections from the Team

What surprised you the most while working on the CVE automation bot?

I was originally not going to write the tool in PHP, because for the task this tool performs you could pick any language — it doesn’t matter. In my first job I worked with PHP but it’s not something I’ve touched in 20 years. So, I was very rusty and knew I would be faster using something I’m more experienced with. But then it would be easier for the project to take ownership of the tool and maintain it long term if it’s written in their language.

When I first learned PHP you just had functions; since then classes have been added. The project has added lots of other things, like generators, which were really convenient for reading the feed of CVEs. That’s a really nice way of streaming data without loading a whole lot of memory all at once. It has gotten better in the sense it has gained features that are convenient. The documentation has always been very good and very comprehensive, that’s always been one of its main strengths.

What was especially challenging about this project?

The main challenge that building a CI-based tool added was trying to work out how to store data that needed storing. There are some features of the GitHub platform that let you take some files that were generated by one task and have a later task download them. You could kind of use that to store some data away and then upload it somewhere, and next time your program runs, download it and update it. You can do that in a loop. It’s kind of a hack, but it works okay. It’s less convenient than using a database service, but it was a fun wrinkle to deal with.

What lessons did you learn working on PHP that will benefit the project going forward, or that you will bring into future projects?

Making something on GitHub Actions that stores a state was one of the most interesting bits of this to me. Now that I know how to do that, it’s a useful trick to have up my sleeve.

I also learned a bit about how the CVE ecosystem works, which is useful for this but is also a useful background for just working with software. There are a bunch of services that already exist that will notify you when a vulnerability affects one of your dependencies, including GitHub. They make it look kind of simple. And now, having looked at the source data for where this stuff comes from… it’s not simple whatsoever! The source is really messy, and there are lots of different origins for it. They all have different APIs and they all give you different slices of the information. Some of them will tell you in a very fine-grained way which parts of the software it relates to, some of them won’t do it at all, and some will do something in the middle.

I’ve had experience in the past of people coming to my projects and saying, “Hey, I”m getting a security warning about this release, please fix it,” and I can only say “That’s not real, I don’t know what notified you but that’s already been fixed.” Now that I’ve seen where the data comes from, I can understand how that happens. It is difficult in general to determine what software is affected by any particular vulnerability.

Conclusion

We want to share a HUGE thank you with the PHP team for inviting us to lend a hand. We had the opportunity to help project members in a very direct way across both seasons, which is really gratifying for us.

You can read more about our work with the Sovereign Tech Agency and the projects we’ve worked on with their support:

Keep up to date with future projects by joining our newsletter.

« Back to the blog post overview
og-image-preview