Turbo EA runs on your own infrastructure, so you should be able to see how it is protected. Every change to Turbo EA starts at the centre and passes through each of the layers below before it reaches your installation. The outer layer is the part your IT team looks after.
9layers of protection
41safeguards
Dailyvulnerability re-scan
Weeklyautomated penetration test
Nine layers, from the first idea to your servers
Select a ring or a layer to see what it does. Pick a moment in the life of a change to light up the layers that are at work at that point.
When each layer is at work
Pick a moment to light up the layers that are at work at that point.
Turbo EA is built with the AI coding assistant Claude Code. Every change starts as a written request, and security is part of that request from the start.
While writing
Every request names the risk
Before any code is written, the request states who may use the feature, what data it touches and who must never see it. The plan is reviewed before the code, and the same person reviews the result.
Written security rules for every session
The assistant reads the project’s security rules at the start of every session. They require permission checks on every action, including reading data, validated input everywhere, no hand-written database queries and encrypted credentials.
A checklist on every change
Every pull request carries a checklist that covers permissions, database changes and exposed data, so a skipped item stays visible to the reviewer.
Layer 02 of 09 · Rules a future change cannot forget
Rules built into the code
Important security rules are written into the code and backed by automated tests, so a later change cannot quietly undo them.
While writing
Before saving
In review
Permission checks on every action
Every action that changes data checks the person’s permissions first, and the data a person reads is filtered to what their role allows.
Hidden data stays hidden
If a role may not see a type of card, Turbo EA behaves as if those cards do not exist. An automated test checks that every part of the API that returns cards applies this same visibility rule.
Checks before every commit
Before a change is committed, local checks format and lint the code and scan it for passwords and keys with Gitleaks.
Encrypted credentials
The credentials Turbo EA stores, such as those for single sign-on, email, AI providers and integrations, are encrypted in the database rather than kept in plain text.
Layer 03 of 09 · Automated checks on every change
Checks before every merge
Turbo EA’s code lives on GitHub. Every proposed change, called a pull request, goes through automated checks before it is merged.
In review
On merge
Every week
Code scanning with GitHub CodeQL
GitHub’s CodeQL engine analyses the Python and TypeScript code and the build workflows for security flaws on every pull request and again every week. Findings appear in the repository’s Security tab, and serious ones are fixed or dismissed with a written reason.
Secret scanning with Gitleaks
Every pull request and every change to the main branch is scanned for passwords, keys and tokens, and a finding fails the check.
Vulnerable packages blocked
Whenever a change touches the application, its third-party packages are checked against public vulnerability databases with pip-audit for Python and npm audit for JavaScript. A known vulnerability fails the check.
Tests and quality checks
The unit tests, the code-quality checks and a check that the published API description is up to date run on every change, and any failure fails the pull request.
Trusted authors only
A GitHub Actions workflow automatically closes pull requests from accounts outside a short list of approved authors.
Layer 04 of 09 · Proof of where the software came from
Signed releases
Turbo EA is delivered as five container images and a Helm chart for Kubernetes, published on GitHub Container Registry. Each one is digitally signed, so you can prove it came from the official build and has not been altered.
On merge
On release
Keyless signing with Sigstore
Every image and the Helm chart are signed with Sigstore’s cosign, using a short-lived certificate issued to the GitHub Actions build itself. The signature is recorded in Sigstore’s public transparency log, and there is no long-lived signing key that could leak.
Checked straight after signing
Right after signing, the build verifies the signature with the oldest cosign version that the documentation supports, so a signature you could not check is caught immediately.
A list of what is inside
Every image carries a software bill of materials (SBOM) in SPDX format, which lists every component inside it, and a provenance record of how it was built.
Pinned build tools
Every GitHub Action used by the build is pinned to an exact version, so a changed or compromised release of one cannot slip in unnoticed.
Containers with minimal rights
The application containers run as a non-root user with all extra Linux privileges removed, and the Helm chart also makes their file system read-only.
Layer 05 of 09 · Checked at release and every day after
Vulnerability scanning
New vulnerabilities are discovered every day, so the published images are scanned when they are built and again every morning.
On merge
Every day
Every week
Two independent scanners
Trivy from Aqua Security and Docker Scout each check the images against their own vulnerability databases, and the results go to GitHub’s Security tab. A critical vulnerability with an available fix fails the build.
Daily re-scan with automatic repair
Every morning the published images are scanned again. When a fix becomes available for a high or critical vulnerability, a rebuild of all five images starts automatically.
Weekly fresh rebuild
Every Monday the images are rebuilt from scratch, which picks up the latest security patches for the operating system inside them.
Layer 06 of 09 · The running application, tested from outside
Automated penetration test
Every week, the released version of Turbo EA is started exactly as you would run it and tested from the outside, the way an attacker would first look at it.
Every week
The real application, as you would run it
Every Tuesday, the published images are started with the standard Docker Compose file in production mode and loaded with sample data, so the test sees what you would install.
Tested as a visitor and as an administrator
OWASP ZAP explores every page and API route it can reach twice: once as an anonymous visitor and once signed in as an administrator.
What it looks for
The test checks for missing or weak security headers, unsafe cookie settings and information leaks. It observes the application and never changes data.
Every finding is acted on
Any finding that has not been reviewed and accepted with a written reason fails the run. Findings so far led to fixes such as hiding the web server version and tightening the Content Security Policy.
Layer 07 of 09 · Third-party components, kept current
Up-to-date dependencies
Like most modern software, Turbo EA is built on open-source components. They are updated on a fixed schedule, so fixes arrive without anyone having to remember.
Every week
Every month
Every quarter
GitHub Dependabot
Dependabot watches Turbo EA’s dependencies for published security advisories and proposes fixes. Every week it also proposes updates for the base images, such as nginx, PostgreSQL, Python and Node.
Monthly updates
Once a month, the GitHub Actions used by the build and the embedded editors for diagrams, process models and data grids are brought up to date.
Quarterly review of exceptions
Every vulnerability that was accepted with a written reason is reviewed each quarter, and the exception is removed once a fix exists.
Layer 08 of 09 · On by default in every installation
Protection inside the application
These protections are part of Turbo EA itself and are active in every installation, with no configuration needed.
In production
Secure sessions
Your session is kept in a cookie that scripts on the page cannot read, and passwords are stored as bcrypt hashes. After five failed sign-in attempts, the account is locked for 15 minutes.
Safe production settings
In production mode, Turbo EA refuses to start with the example secret key from its documentation and switches off its developer API documentation.
Access rights everywhere
Roles decide what each person can see and change. A card type that is hidden from a role disappears for that role from lists, search, reports and exports.
Browser protection
Every page is sent with a strict Content Security Policy and other browser security headers that guard against common attacks such as cross-site scripting and clickjacking.
Safe file uploads
Uploaded files are checked by their actual content, not by the name or type the browser reports, and size limits apply.
Signed extensions and careful AI
Extensions only install with a valid vendor signature. AI assistants connected through the Model Context Protocol (MCP) preview every change before it is saved, and large changes need an extra confirmation.
Layer 09 of 09 · What your IT team adds
Your part
Security is shared. The outer layer is what your IT team does when it installs and runs Turbo EA, and the documentation explains each step.
In production
Verify the signature
Before you deploy, check each image and the Helm chart with cosign. The documentation gives the exact commands and shows how to read each image’s bill of materials.
Pin the version and keep backups
Install a specific release rather than the moving latest tag, and back up the database and the data volume before every upgrade.
Protect the secret key
Generate a long random secret key for your installation and keep it safe. It signs every session and protects the credentials Turbo EA stores.
Use HTTPS
Serve Turbo EA over HTTPS, through the bundled web server, your Kubernetes ingress or your cloud provider. HTTPS is also what marks the session cookie as secure.
Keep it off the open internet
Turbo EA does not need to be reachable from the public internet, and the recommended setup keeps it off it. Best practice is to let only approved corporate devices reach it, for example through your VPN, a zero-trust access gateway or the device-compliance rules of your identity provider.
Sign in through your identity provider
Connect Microsoft Entra ID, Google Workspace, Okta or any OpenID Connect provider, and enforce multi-factor authentication there.
Least privilege
Give each person only the access they need with custom roles, and deactivate people when they leave.
Report issues privately
If you find a security issue, report it through GitHub’s private vulnerability reporting so it can be fixed before it is made public.
Boundaries
Out of scope, on purpose
lock_person
Multi-factor authentication
Turbo EA has no built-in second factor. People should sign in through your identity provider, such as Microsoft Entra ID, Google or Okta, which enforces multi-factor authentication. Accounts that use a local password have no second factor.
radar
Attack-mode testing
The weekly penetration test observes the application and never changes data. Tests that try to break in by sending harmful input, and manual penetration tests of your own installation, are for your security team to run.
dns
Your own environment
Turbo EA’s checks cover its published images in their default setup. Your servers, network, proxy and identity provider are yours to check, and the signed images with their bills of materials give your tools a reliable starting point.
See it for yourself
Every safeguard on this page is set up in Turbo EA’s public GitHub repository, so your security team can check each one. The security pipeline document gives the full technical detail, and vulnerabilities are reported privately through GitHub.