I applied for GitHub's security fund. Then CodeQL found 42 alerts.

I had just submitted Aelira Core's application to the GitHub Secure Open Source Fund.

We had explained why security matters to our project, how we handle findings, and why expert help would be valuable.

Then I suggested turning on CodeQL, GitHub's code analysis tool for finding potential security problems.

42 alerts on the first scan.

Excellent timing.

I have spent the last ten months building Aelira and funding the work myself. Aelira Core is our open-source accessibility platform for higher education, still in beta. The aim is to help people make course materials usable without changing the information students receive.

We already had security tests, dependency checks and a reporting policy. CodeQL found gaps and paths those checks had missed or needed us to investigate more closely. I would prefer to have caught them earlier.

What the scan actually found

The first scan raised 42 alerts. Follow-up analysis brought the tracked total to 44, with CodeQL severity labels of two critical, 35 high and seven medium.

Those labels describe scanner findings. They do not establish 44 distinct, exploitable vulnerabilities. We had to trace the reported paths, check the existing controls and decide what needed changing.

As checked on 8 October, the result is:

• 25 alerts marked fixed after source changes.
• 19 individually reviewed and dismissed with recorded explanations.
• Zero open alerts in this tracked set.

The dismissals need explaining too. Some reports did not describe a vulnerability in the code they flagged. Others remained after we strengthened the relevant guards, because the scanner did not recognise those controls. Calling all 19 harmless false alarms would leave out part of the work.

No query exclusions were added. The individual dismissal reasons are recorded in GitHub; they can be challenged if new evidence changes the assessment.

What changed, and why it matters

We prioritised the highest-severity findings and tracked the response through issues, code changes and regression tests. The merged work strengthens outbound requests, upload handling, browser credential storage, error handling and logging.

There is an accessibility consequence here as well. Image descriptions must require the actual image. If the vision model cannot receive verified source pixels, the workflow must stop and leave the issue for review. A plausible description generated without seeing the image is not a repair.

Similarly, a scan that cannot evaluate the resources it needs must say it is incomplete. It should not hand someone a reassuring score.

A bad repair can change what a student learns. A security failure can expose the documents or credentials an institution trusted us to handle. These boundaries need the same care as the accessibility work itself.

What reached the hosted service

The changes are merged into Aelira Core's main branch. On 8 October, we also backported the shared fixes into our hosted API, worker and dashboard and deployed them. We checked the running source and served dashboard assets against the tested revision, alongside database and queue readiness.

There is a visible tradeoff: dashboard API keys are now held in memory, so API-key users need to re-enter them after a full reload. Cookie-session recovery remains available.

Self-hosted installations need their own update. At this checkpoint, the latest tagged release is still v0.9.11 and does not contain these changes. The public remediation PR identifies the merged revision and compatibility effects; use that record when planning and testing an update.

The deployment work exposed a testing problem too. A hosted browser-security CI lane had shown green while skipping all its cases. We corrected the gate so missing or skipped cases fail it, then verified all 15 required cases ran and passed.

The earlier Core validation is separate: its final Linux backend run passed 8,242 tests, with 269 existing policy-allowed skips. Dashboard and CLI checks passed, and post-merge CI completed successfully. The public PR records the testing scope and limitations.

I used AI coding assistance throughout the investigation and remediation. Acceptance depended on reviewing the code, regression tests, CI results and browser checks. External expert review can still find things this process missed.

What remains

Other dependency advisories, scanner findings and operational follow-ups remain under review. Zero open in this CodeQL set does not mean the whole security backlog is empty, or that the software has no vulnerabilities. Prospective logging fixes also do not erase historical logs; that follow-up is separate.

Our grant application is still pending. GitHub has not awarded us funding or endorsed the project. The programme's security education and expert guidance would help us challenge our assumptions and make this work more sustainable for a small maintainer team.

I want Aelira to be built in public. That includes the awkward timing, the findings we needed to fix, the dismissals we need to explain and the test gate that needed correcting.

I am glad we turned the scanner on.

If you maintain an open-source project and have been meaning to add another security check, leave time to investigate what comes back. Explain the dismissals as carefully as the fixes. And check what is running in production as well as what is merged in Git.

The changes and test record are public. We welcome careful review; please report suspected vulnerabilities privately through our security policy.

• Remediation PR
• Post-merge CI
• Source code
• Security reporting policy
• GitHub Secure Open Source Fund
• How GitHub records fixes and dismissals