# Assemblyline 4: a Kubernetes platform for file triage and malware analysis > Assemblyline 4 is an open source malware analysis framework from the Canadian Centre for Cyber Security that runs on Kubernetes and Docker, from a small appliance for manual analysis to enterprise scanning of millions of files a day. The interesting part of the repository is that it is a monorepo of separately released components rather than one application. **CybercentreCanada/assemblyline** — Assemblyline 4: File triage and malware analysis - Repository: https://github.com/CybercentreCanada/assemblyline - Website: https://cybercentrecanada.github.io/assemblyline4_docs/ - Stars: 561 · Forks: 46 - Language: Python - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cybercentrecanada-assemblyline ## What Assemblyline is for, and the scale it claims to cover Assemblyline 4 is an open source malware analysis framework that uses Kubernetes and Docker to adapt to many use cases, from a small appliance for supporting manual malware analysis and security teams to large-scale enterprise security operations scanning millions of files a day and providing triage capabilities. That range is the point of the Kubernetes choice. A triage analyst opening one suspicious attachment and a SOC ingesting a mail gateway's daily quarantine both need file analysis, and the difference is roughly three orders of magnitude in volume and a completely different tolerance for latency. A platform that scales by adding workers and that runs each analysis tool in its own container can serve both, and a single-process analyser would serve one or the other badly. The system is described as a scalable file triage and malware analysis system integrating the cyber security community's best tools, and the French version of the README carries the same claim in the same framing, with a French documentation site alongside the English one. Integration is the other emphasis. Assemblyline can be integrated into an environment using its REST API and web interfaces, and the platform comes with dozens of services providing deep file analysis and integration with other security platforms such as anti-virus, malware detonation sandboxes and threat knowledge bases. The extension story is Python: with a little bit of Python code you can extend it by creating new analysis and integration services. That last point is what makes this more than a product. A triage platform is only as good as the tools plugged into it, and every organisation has tools the community has not heard of. The service model is the extension point. The project is MIT licensed, the last push was on 2026-10-22, and the homepage is the Assemblyline 4 documentation site. The topic list of the repository is long and tells you the intended audience: incident response, malware analysis and detection, file and document analysis, security automation, and the automation framework in general. ## This repository is the assembly line, not the product The README has a section asking what the purpose of the repository is, and the answer is short. This is a repository containing development resources for the Assemblyline project. The top level listing explains what that means in practice. There are directories for assemblyline-base, assemblyline-core, assemblyline-mcp, assemblyline-service-client, assemblyline-ui, assemblyline-ui-frontend and assemblyline-v4-service, plus build-image/ and root-image/ directories for container builds, a pipelines/ directory, an img/ directory, and gen_docs.py for documentation generation. So the application is split across several repositories, and this one holds them as submodules, alongside the container build definitions and the documentation tooling. The core components table in the README is the map. It has columns for repository name, main branch, dev branch and PyPI release, and it covers Assemblyline Base, Assemblyline Core, Assemblyline Service Client and Assemblyline UI, each with its own GitHub repository, its own Azure test status badges for the master and dev branches, and its own PyPI release. The presence of a dev branch alongside master for every component, with separate test status for each, tells you the branching model. The master branch is what gets released, and dev is where work in progress lands, and the CI badges let you see at a glance whether a given component is currently green on each branch. The three headings tell you what each piece is. Base is the foundation layer that the others build on. Core is the analysis and service layer, which is where the dozens of analysis services live. Service Client is the library that talks to Core, so an external tool can submit files and read results. And UI is the web interface, with a separate ui-frontend directory for the JavaScript side and a separate v4-service for the back end of the current major version. assemblyline-mcp appears in the tree but not in the visible part of the components table, which suggests an additional component that the table section does not cover, most likely an interface exposing Assemblyline to a model context protocol client, though the README text available here does not describe it. ## What the platform does with a file once it arrives The README does not walk through the file processing pipeline in detail, so the reliable statements are about scope rather than mechanism, and it is worth being clear about that rather than inventing a pipeline. What is stated is that the platform comes with dozens of services to provide deep file analysis, and that those services integrate with other security platforms such as anti-virus, malware detonation sandboxes and threat knowledge bases. That list tells you the shape of a triage system. Detonation sandboxes are for files that are not safely analysable by static means, so an assembly line has to be able to hand a sample to something that will execute it in a controlled environment and report back. Anti-virus integration means the platform consumes verdicts from engines you already run rather than duplicating them. Threat knowledge bases mean it can enrich a file with known-bad indicators and, more usefully, recognise a file that has been seen before in your own environment. The file triage framing is also meaningful and distinct from full analysis. Triage is the step where a large queue of files gets sorted by suspicion so a human can look at the interesting ones, and the phrase providing triage capabilities is the one the README uses for the large-scale case. A platform that scans millions of files a day is not scanning them all deeply, because that would not be affordable. It is scoring them and escalating. The two supported deployment shapes follow from the same reasoning. The small appliance is for a manual analysis team, where a person is present and the throughput requirement is modest. The enterprise configuration is for organisations with a queue that arrives continuously and a requirement to show evidence and disposition for every file. The REST API is what makes both usable in a pipeline rather than as an application people sit in front of, and the Python service model is what makes the set of tools the platform runs something you control rather than something fixed. ## The repository layout, and where the operational work lives The directory listing of this repository is a map of how the project is built and released. The .github directory holds the GitHub configuration, and .gitmodules is what makes the component repositories into submodules of this one. That single file is the mechanism behind the whole design: a developer clones this repository and gets all the components at known revisions, and the component repositories remain independently versioned and independently released. The build-image/ and root-image/ directories are the container definitions, and their presence tells you that the deployment is a set of images rather than an installer script. A platform with dozens of analysis services, each with its own tool dependencies, is not something you install with pip into a virtualenv and run; it is a set of containers orchestrated by Kubernetes, and the images are the unit of distribution. The pipelines/ directory holds the CI pipeline definitions, and gen_docs.py at the root is the documentation generator, which makes sense for a project whose documentation spans several repositories and has to describe them together. The governance files are conventional. There is a CONTRIBUTING.md for contributors, a SECURITY.md for vulnerability reports, and LICENCE.md, with a different filename from the usual LICENSE, which is worth noting if you are grepping for licence files across a fleet of repositories. The img/ directory holds the logo assets, including the dark SVG that appears at the top of the README, and the Discord badge and member count in the README point at a community chat with a substantial membership, which is the usual sign of a project that expects to be operated by a community rather than only by its authors. ## Release naming, and the difference between this repository and PyPI The recent releases in this repository are named v4.7.5.dev150, v4.7.5.dev149 and v4.7.5.dev148, all within a few days of each other in October 2026. That naming is worth pausing on, because it is not how a stable product is versioned. The dev suffixes with an incrementing counter are development builds. They correspond to the dev branch of the components rather than to anything on PyPI, and they are how the platform is made available to operators who want the current state rather than a tagged release. The dev branch has its own test status badge per component, so a dev build is built from branches that are, in principle, green. The stable artefacts live elsewhere, in the PyPI releases of the individual components. The components table links the PyPI release history for assemblyline, assemblyline-core, assemblyline-service-client and assemblyline-ui separately, each with its own latest stable release badge. That is the practical consequence of the split. If you are deploying, you choose a version per component, and the components table is the place to check what the current stable release of each is. If you are tracking the development of the platform as a whole, the dev builds here are what move, and they move daily. For a security operations team, the version numbers of the analysis services matter a great deal, because a new service version can change how a file is classified. The separate release lines make it possible to hold one service at a known version while upgrading another, which is the same property you want from any componentised system, and it is a direct consequence of publishing each piece on its own cadence rather than as one monolith. ## Conclusion Adopt Assemblyline 4 if you need a file triage and malware analysis platform that runs the community's best tools behind a REST API and a web interface, and you have Kubernetes or Docker available. Do not adopt it expecting a single pip install, because the platform is a set of separately versioned services that have to be deployed together. Before you plan the deployment, read the Assemblyline 4 documentation site, decide which analysis services you actually need, and check the subcomponent repositories for the current release, since this repository publishes development builds rather than the stable versions you would deploy. ## FAQ ### What is Assemblyline 4? It is an open source malware analysis framework from the Cyber Centre Canada that leverages Kubernetes and Docker, ranging from a small appliance for manual analysis and security teams to enterprise operations scanning millions of files a day with triage capabilities. The system is described as integrating the cyber security community's best tools. ### Which components make up the Assemblyline platform? The core components table lists Assemblyline Base, Assemblyline Core, Assemblyline Service Client and Assemblyline UI, each with its own repository, its own master and dev branch and its own PyPI release. The tree also holds assemblyline-mcp, assemblyline-ui-frontend, assemblyline-v4-service, build-image and root-image directories, plus the pipelines and documentation tooling. ### How do I extend Assemblyline with my own tools? With a little bit of Python code you can create new analysis and integration services, and the platform comes with dozens of services for deep file analysis and integration with other security platforms such as anti-virus, malware detonation sandboxes and threat knowledge bases. ### Why are the Assemblyline releases named like v4.7.5.dev150? Those are development builds corresponding to the dev branch of the components rather than to a stable release. The stable artefacts are the PyPI releases of each component, which the components table links separately with their own latest stable release badges. ### Where is the Assemblyline documentation? At the Assemblyline 4 documentation site linked from the README, with a separate French documentation site alongside it. The repository also carries a gen_docs.py script and a pipelines directory, so the documentation is generated from the repositories rather than maintained separately. ## Sources - [CybercentreCanada/assemblyline on GitHub](https://github.com/CybercentreCanada/assemblyline) - [License: MIT](https://github.com/CybercentreCanada/assemblyline/blob/master/LICENSE) - [Project website](https://cybercentrecanada.github.io/assemblyline4_docs/) - [README](https://github.com/CybercentreCanada/assemblyline/blob/master/README.md) - [Releases](https://github.com/CybercentreCanada/assemblyline/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cybercentrecanada-assemblyline