Taking Our Core Computational Pipeline Private
Beyond our own biosurveillance work, we at SecureBio Detection consider it part of our mission to advance the science of infectious disease monitoring as a whole. In that spirit, we have historically made much of our computational pipeline public, including our core nao-mgs-workflow repository. This public stance has had many benefits, making it easier for us to collaborate with academic and other nonprofit partners, blog about our work in more detail, and publish our analyses in the academic literature.
However, this open approach has also had costs, and the ratio of costs to benefits has shifted over time. As we grow in scale and prominence and shift our focus toward actually running an effective biosurveillance system, we believe the costs have unfortunately outpaced the benefits.
Consequently, we have made the difficult decision to shift future development of our core pipelines to private repositories. While our existing public repositories will remain accessible, future updates will move to private forks, and we will use these private codebases for our own data processing going forward. The rest of this post elaborates on this decision, and what it means for those who follow or work with SecureBio Detection.
Why are we doing this?
The primary reason for this change is security. As the barriers to building harmful pathogens continue to fall, it is increasingly untenable to have the details of our detection methods out in the open for malicious actors to read and adapt to. While we don’t believe our current pipeline is especially sensitive, we have a variety of changes and improvements planned that we don’t feel comfortable making fully public. This applies to the pipeline itself, to the reference databases we use to run it, and to the details of our internal infrastructure, any of which could potentially be engineered around by a malicious actor keen to avoid detection.
In addition to security, there are practical reasons for the change. Historically, we have built nao-mgs-workflow with external users in mind, which has placed major constraints on its design and our ability to integrate it tightly into our internal systems. As our infrastructure and automations grow more complex and sophisticated, the work of maintaining the pipeline as something usable by others has become increasingly burdensome to our computational team. Taking the pipeline private will allow us to stop treating it as a special case and will both simplify and deepen its interconnections with the rest of our systems.
Finally, shifting to a private development pipeline will allow us to lean even more heavily into AI-assisted development. Like many groups, we are increasingly relying on AI coding agents for much of our computational work, and we have built scaffolds and systems to increase the safety and effectiveness of these AI systems for our use cases. nao-mgs-workflow’s status as a public pipeline creates prompt injection and data exfiltration risks not present for our other codebases, and avoiding these risks reduces the degree of AI acceleration we can achieve. Although there are ways of mitigating some of these issues while keeping nao-mgs-workflow public, taking it private allows us to do so more aggressively while avoiding additional development burden.
What does this mean for our public pipeline?
The existing nao-mgs-workflow repository is not going away and will remain fully public. However, beginning in the next few weeks, we will shift new development over to a private fork, and future releases will take place there. Shortly thereafter, we will update our internal automations and infrastructure to point to the private codebase. We will also triage open issues and pull requests and select some to transfer to the new private repository.
We’re still thinking about how much to update the public repository going forward, if at all. We tentatively expect occasional updates to port over select features from the private codebase – for example, for the sake of publications requiring code disclosure – but otherwise not to maintain the code or fix bugs. However, the details remain to be finalized. Similarly, while we hope to make high-level updates on our computational approach in blog posts and elsewhere, the frequency and depth of these remain to be determined.
We’ll continue to communicate with our partners about analytic changes affecting the results they get, including high-level descriptions of algorithmic changes and takeaways for interpreting the processed data. However, we don’t expect to share private code with partners in most cases. This approach is in line with the way we manage our existing private codebases, such as Chimera Detection.
Conclusion
We still believe fervently in the importance and potential of the wider biosurveillance field. While we understand this change will disappoint some, we’ll continue to engage with the communities of research and practice we’re part of, both in person and in writing, and share thoughts and advice on methods and approaches. We believe the future is bright for this work, as more and more governments and other groups take an interest and the available funding continues to grow. At the same time, we cannot ignore the need for responsible practice in a world in which dangerous biological capabilities are increasingly widespread. We are making this change to position ourselves to have the most positive impact we can in this future; to set an example of what we believe is good practice; and to support and empower our computational team as they work toward a safer world.