# Introduction
What is DevArmor and how can it help you scale your AppSec operations?
## What is DevArmor?
DevArmor automates threat modeling, security design reviews, and enforcement. It replaces hundreds of hours of design reviews and manual code checks with fully automated security operations.
DevArmor helps security and engineering teams:
* Automate threat modeling from natural language specs, architecture diagrams, and Jira tickets.
* Review and validate security design decisions before a single line of code is written.
* Enforce security policies across GitHub, CI/CD, and infrastructure-as-code.
* Provide secure building blocks, pre-approved design patterns and reference implementations that AI and human contributors can safely assemble from.
DevArmor eliminates AppSec’s manual toil while providing the security and engineering teams with 360-degree visibility, control, and operational scale.
## How does DevArmor work?
DevArmor integrates with your engineering workflows to deliver security insights and suggest actions based on specific security plan and threat model of the organization.
### Threat Modeling
Create a threat model in minutes, instead of weeks, by uploading PRDs, RFCs, documentation, vulnerability reports, SAST results, architecture diagrams, and other artifacts.
### Security Review
Review every feature by integrating DevArmor with your issue tracking platform. DevArmor automatically reviews every new issue, determines whether it has security significance, and performs an automated security review. The output of the security review (requirements, recommendations, and controls) are delivered to the developers in the issue tracking platform.
### Code Review
DevArmor's Code Review module is a GitHub App that reviews every PR to find potential security vulnerabilities and deviations from security requirements and controls. It correlates code changes with security review results and flags deviations from design patterns.
When possible, DevArmor also suggests remediation for the issues it finds (beta).
## Why DevArmor?
The future of AppSec isn’t about chasing bugs or triaging alerts. It’s about capturing intent, governing design, and enabling every contributor (human or AI) to build securely by default.
As AI-native tools take over more of the implementation, the biggest AppSec risks will shift upstream, from insecure code to insecure design. That means the focus of security must shift as well, from scanning and remediation to governance of architecture, workflows, and decisions.
At DevArmor, we see this shift as both inevitable and exciting.
We’re building the foundation that lets AI work within security with clear requirements, defined guardrails, and verified design intent.
DevArmor:
* Automates threat modeling and design reviews.
* Integrates seamlessly into dev workflows (Jira, GitHub, Notion).
* 3x productivity boost for AppSec teams; 25–30% faster releases.
\
# How to get started
How to sign up and start using DevArmor.
DevArmor is a web application, with integrations into popular engineering platforms.
We currently support Enterprise installation. To install DevArmor on your codebase, start by emailing our team at .
We will reach out to you to create an account for you and help you onboard.
# API Access
Authenticate and make your first request to the DevArmor API.
## Overview
DevArmor exposes a REST API covering the same functionality as the web app — projects, threat models, design reviews, policies, and more. All endpoints accept and return `application/json`.
* **Base URL:** `https://secrev.api.devarmor.com`
* **Interactive reference:** (Swagger UI, generated from the live OpenAPI spec — the source of truth for request/response schemas and every available endpoint)
## Authentication
The API authenticates requests with a bearer token. Send it on every request as:
```
Authorization: Bearer
```
Requests without a valid token receive a `401 Unauthorized` response.
### Creating an API token
1. Sign in to the DevArmor web app.
2. Go to **Settings → API Tokens**.
3. Click **Create token**, give it a title, and set an expiration date.
4. Copy the token when it's shown — it's only ever returned once, at creation time.
Once you hold one token, you can also manage tokens through the API itself:
| Method | Path | Purpose |
| -------- | ------------------------ | ----------------------------------------------------------- |
| `GET` | `/api-tokens` | List your tokens (titles/expiry only — not the token value) |
| `POST` | `/api-tokens` | Create a new token |
| `DELETE` | `/api-tokens/{token_id}` | Revoke a token |
Tokens are scoped to the user that created them and inherit that user's permissions.
## Making your first request
A couple of endpoints don't require authentication and are useful for confirming connectivity:
```sh
curl https://secrev.api.devarmor.com/status
# {"status":"ok","api_version":"1.9.0"}
```
Once you have a token, confirm it works by fetching your own user record:
```sh
curl https://secrev.api.devarmor.com/users/current \
-H "Authorization: Bearer "
```
From there, most work happens under `/projects`:
```sh
curl https://secrev.api.devarmor.com/projects \
-H "Authorization: Bearer "
```
## Errors
* **`401 Unauthorized`** — missing, invalid, or expired bearer token.
* **`422 Unprocessable Entity`** — request body or parameters failed validation. The response body lists each failing field:
```json
{
"detail": [
{ "loc": ["body", "expires_at"], "msg": "Field required", "type": "missing" }
]
}
```
## Next steps
Browse the full set of endpoints — projects, threat models, design reviews, policies, rules, integrations, and more — in the [interactive API reference](https://secrev.api.devarmor.com/docs).
# MCP Access
Connect Claude, ChatGPT, and other MCP clients to DevArmor.
## Overview
DevArmor runs a remote MCP (Model Context Protocol) server, so AI assistants — Claude Desktop, Claude Code, ChatGPT, and other MCP-compatible clients — can call DevArmor's threat-modeling and security-review tools directly instead of going through the REST API by hand.
* **Endpoint:** `https://secrev.mcp.devarmor.com/mcp`
* **Transport:** Streamable HTTP
## Authentication
The MCP server uses the same bearer token as the [API](/getting-started/api-access). If you don't have one yet, create it from **Settings → API Tokens** in the DevArmor web app.
Send it as a header when connecting a client:
```
Authorization: Bearer
```
## Connecting a client
In each example below, replace `` with your DevArmor API token.
### Claude Desktop
Claude Desktop only launches local clients and can't connect to a remote MCP server directly. Connect through the `mcp-remote` proxy, which ships as an `npx` package (requires Node.js).
Edit your Claude Desktop configuration file:
* macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
* Windows: `%APPDATA%\Claude\claude_desktop_config.json`
Add the server:
```json
{
"mcpServers": {
"DevArmor": {
"command": ".../npx",
"args": [
"-y",
"mcp-remote@latest",
"https://secrev.mcp.devarmor.com/mcp",
"--header",
"Authorization:Bearer "
]
}
}
}
```
> **Note:** `command` needs the full path to `npx` (find it with `which npx`) — Claude Desktop launches with a minimal `PATH` and often can't resolve a bare `npx`. Also note there's no space between `Authorization:` and `Bearer` — a known `mcp-remote` quirk.
Fully quit and restart Claude Desktop. DevArmor then appears under **+ → Connectors**, with its tools available to both chat and code mode.
### Claude Code CLI
```shell
claude mcp add --transport http --scope user "DevArmor" \
https://secrev.mcp.devarmor.com/mcp --header "Authorization: Bearer "
```
Prefix the command with a space ( `claude` instead of `claude`) so your shell doesn't save the API key to its history file.
`--scope user` makes the server available in every project; drop it, or use `--scope project`, to scope it to one project instead.
Verify with:
```shell
claude mcp list
```
### ChatGPT Desktop
Go to **Settings → Plugins → Add → Add MCP server** and fill in:
* **Name:** DevArmor
* **Type:** Streamable HTTP
* **URL:** `https://secrev.mcp.devarmor.com/mcp`
* **Header:** `Authorization` / `Bearer `
Fully quit and restart the ChatGPT desktop app. This also makes the server available in the Codex CLI. There's currently no way to use it from ChatGPT's web/chat mode.
## Next steps
Once connected, ask your assistant to list its available tools to confirm the connection, then see the [API reference](/getting-started/api-access) for what each tool maps to under the hood.
# Single Sign-On (SSO) Authentication
DevArmor supports **social authentication** and **Single Sign-On** through enterprise identity providers, allowing users to sign in securely using their existing accounts.
Currently supported providers:
* Google
* Microsoft
* Okta
* OneLogin
This allows organizations to simplify user access while leveraging their existing identity and access management policies.
| Provider | Authentication Method |
| --------- | --------------------------------------- |
| Google | OAuth 2.0 (Google Sign-In) |
| Microsoft | OAuth 2.0 / Microsoft Identity Platform |
| Okta | OIDC |
| OneLogin | OIDC |
Users can authenticate using their **existing Google Workspace, Microsoft, Okta, or OneLogin account** without needing to create a separate DevArmor password.
## How Users Sign In
1. Navigate to the **DevArmor login page:** [**https://app.devarmor.com/sign-in**](https://app.devarmor.com/sign-in)
2. Select one of the available sign-in options:
* **Sign-in with Google**
* **Sign-in with Microsoft**
* **Sign-in with Okta**
* **Sign-in with OneLogin**
3. Authenticate with your identity provider
4. After successful authentication, you will be redirected to DevArmor
If it is the user’s first time signing in, reach out to to request a new account to be created. Alternatively, contact your organization's admin and they will be able to create an account for you on DevArmor platform.
## Admin Guidance for Organizations
Organizations using **Google Workspace**, **Microsoft Entra ID (Azure AD)**, **Okta**, or **OneLogin** can allow their users to sign in with their existing accounts. Okta and OneLogin require a one-time setup by your admin — see [Okta SSO (Manual)](/getting-started/single-sign-on-sso-authentication/okta-sso-manual) or [OneLogin SSO (Manual)](/getting-started/single-sign-on-sso-authentication/onelogin-sso-manual), or install DevArmor straight from OneLogin's App Catalog: [OneLogin SSO (App Catalog)](/getting-started/single-sign-on-sso-authentication/onelogin-sso-catalog).
Recommended best practices:
* Require employees to use their **corporate identity provider account**
* Enforce authentication policies through your identity provider (MFA, device policies, etc.)
* Disable personal email domains if your organization restricts them
Authentication policies (such as MFA requirements) are controlled **directly within your identity provider**.
## Troubleshooting Login Issues
#### User cannot log in
Verify the following:
* The user is signing in with the correct identity provider account. Specifically, make sure they are using the same email address (including domain) as registered in DevArmor.
* The browser allows authentication redirects
* The user has permission to access DevArmor within your organization.
#### Account created with the wrong provider
If a user accidentally signs up using a different authentication provider (for example Google instead of Microsoft):
1. Contact your DevArmor administrator
2. The admin can update the account or merge identities if needed
#### Authentication fails during login
Common causes include:
* Browser extensions blocking redirects
* Expired identity provider sessions
* Organization-level login restrictions
Recommended fixes:
* Try logging in again
* Use a private browser window
* Clear browser cookies for your identity provider
## Security Considerations
DevArmor does **not store user passwords** when using social authentication or SSO.
Authentication security is handled by the identity provider:
* **Google** authentication is managed by Google Identity Services
* **Microsoft** authentication is managed by Microsoft Identity Platform
* **Okta** and **OneLogin** authentication is managed by your organization's own Okta or OneLogin org — DevArmor never sees or stores your password
Organizations should configure security policies (such as **multi-factor authentication**) directly within their identity provider.
## Support
If your team encounters authentication issues, contact:
**DevArmor Support:**
Include the following information when reporting issues:
* User email address
* Identity provider used (Google, Microsoft, Okta, or OneLogin)
* Timestamp of the login attempt
* Screenshot of any error messages
# Microsoft Login (Azure AD)
### Enabling Microsoft Login for Your Organization
To allow your team to sign in to DevArmor using their Microsoft accounts, an Azure AD administrator at your organization needs to complete a one-time setup.
#### What you need
* An Azure Active Directory tenant (any Microsoft 365 or Azure subscription includes one)
* An account with the **Global Administrator** or **Cloud Application Administrator** role
#### Steps
**1. Grant admin consent**
Grant admin consent to the DevArmor application in your tenant by visiting the following URL while signed in as an administrator:
```
https://login.microsoftonline.com/common/adminconsent?client_id=e5a3ca80-f651-4f5b-89ab-622dfa12f7fb
```
You will be prompted to review and approve the permissions DevArmor requests (`openid`, `email`, `profile`). These are read-only and used only for authentication.
**2. Share your Tenant ID**
Share your tenant ID with your DevArmor contact. You can find it in the Azure Portal under:
**Azure Active Directory → Overview → Tenant ID**
***
That's it! DevArmor handles the rest of the configuration on our end. Once complete, your users can sign in with their existing Microsoft credentials.
**Notes**
* Only organizational accounts (e.g. `you@yourcompany.com`) are supported. Personal Microsoft accounts (`@outlook.com`, `@hotmail.com`) cannot be used.
* Individual users do not need to install anything or create a new account.
# Okta SSO (OIN Catalog)
How to set up Okta SSO for your organization's access to DevArmor
### Prerequisites
* A **DevArmor organization account**. If your company doesn't have one, sign up at [https://devarmor.com](https://devarmor.com/) or contact your DevArmor representative.
* **Administrator** access to your Okta org.
* DevArmor enables Okta SSO **per organization**. You'll share your integration details with DevArmor in the steps below; DevArmor activates SSO for your organization, typically within **one business day**.
### Supported features
* **SP-initiated SSO**: users start sign-in from the DevArmor application.
Not supported:
* IdP-initiated SSO (Third-party Initiated Login)
* Just-In-Time (JIT) provisioning — DevArmor provisions users on its side
* Single Logout (SLO)
*(See the* [*Okta Glossary*](https://help.okta.com/oie/en-us/content/topics/glossary.htm) *for feature definitions.)*
### Configuration steps (Okta administrator)
1. In the Okta Admin Console, go to **Applications → Applications → Browse App Catalog**.
2. Search for **DevArmor** and click **Add Integration**.
3. On **General Settings**, enter an application label and click **Done**.
4. Open the **Sign On** tab and copy the **Client ID** and **Client Secret**.
5. On the **Assignments** tab, assign the integration to the users or groups who should access DevArmor.
6. Send the following to DevArmor at [**integrations@devarmor.com**](mailto:integrations@devarmor.com) (see [our guide for a secure transfer](/getting-started/single-sign-on-sso-authentication/encrypting-credentials-for-devarmor)):
* Your **Okta org domain** (for example, `yourcompany.okta.com`)
* The **Client ID** and **Client Secret** from step 4
* The **email domain(s)** your users sign in with (for example, `yourcompany.com`)
7. DevArmor enables SSO routing for your organization and confirms by email.
**Application username format:** email.
### SP-initiated SSO (end users)
1. From your browser, navigate to the DevArmor sign-in page at [**https://app.devarmor.com/sign-in**](https://app.devarmor.com/sign-in).
2. Click **Sign in with Okta** and enter your work email address.
3. You're redirected to your Okta organization to authenticate with your Okta credentials.
4. After successful authentication, you're redirected to the DevArmor dashboard.
### Support
* **Support email:**
* **Documentation:** [https://docs.devarmor.com](https://docs.devarmor.com/)
# Okta SSO (Manual)
### Setting up DevArmor SSO with your Okta
DevArmor supports signing in with your organization's Okta via OpenID Connect. Your Okta administrator needs to register an app and share four values with us. Time required: \~10 minutes.
**Step 1 — Create an OIDC app in your Okta org**
* Okta Admin Console → **Applications → Create App Integration**:
* Sign-in method: **OIDC – OpenID Connect**
* Application type: **Web Application**
* **App name:** `DevArmor`
* **Grant type:** Authorization Code
* **Sign-in redirect URI:** `https://auth.devarmor.com/oauth2/idpresponse`
* Sign-out redirect URIs / Trusted Origins: *(leave blank)*
* **Assignments:** assign the users/groups who should have DevArmor access.
**Step 2 — Confirm the authorization server**
The app uses your org's built-in **`default`** custom authorization server (issuer `https:///oauth2/default`). Its access policy needs to allow this app for the Authorization Code grant with `openid`, `email`, `profile` scopes — the default policy normally does.
**Step 3 — Send DevArmor these four values**
*(please send the client secret over a secure channel — a password manager or encrypted message, not plain email)*:
1. **Okta org domain** — e.g. `your_domain.okta.com`
2. **Client ID** *(from the app's General tab)*
3. **Client Secret** *(from the app's General tab)*
4. **Email domain(s)** your team uses — e.g. `your_domain.com`
We'll enable routing for your domain. Your team then signs in at **`app.devarmor.com`** → **"Sign in with Okta"** → enter their `@your_domain.com` email → they're redirected to your Okta to authenticate.
**Notes**
* You keep full control of your own MFA and sign-on policies — DevArmor never changes them.
* Organizational (work) Okta accounts only; personal accounts aren't supported.
* Questions: `support@devarmor.com`.
# OneLogin SSO (App Catalog)
How to add DevArmor from the OneLogin App Catalog
DevArmor has a dedicated connector in OneLogin's App Catalog, so adding it doesn't require building a custom OIDC app by hand — OneLogin pre-configures the redirect URI and token settings for you. If your OneLogin admin would rather use the generic OIDC connector instead (for example, if the catalog listing isn't visible in your org yet), see [OneLogin SSO (Manual)](/getting-started/single-sign-on-sso-authentication/onelogin-sso-manual).
### Prerequisites
* A **DevArmor organization account**. If your company doesn't have one, sign up at [https://devarmor.com](https://devarmor.com/) or contact your DevArmor representative.
* **Administrator** access to your OneLogin org.
* DevArmor enables OneLogin SSO **per organization**. You'll share your integration details with DevArmor in the steps below; DevArmor activates SSO for your organization, typically within **one business day**.
### Supported features
* **SP-initiated SSO**: users start sign-in from the DevArmor application.
Not supported:
* IdP-initiated SSO (launching DevArmor from the OneLogin portal) — sign-in always starts at `app.devarmor.com`
* Just-in-Time (JIT) provisioning — DevArmor provisions users on its side; authenticating via OneLogin doesn't create a DevArmor account by itself. See [Adding new users after setup](/getting-started/single-sign-on-sso-authentication/onelogin-sso-manual#adding-new-users-after-setup).
* SCIM provisioning
* Single Logout (SLO)
There's currently no public API for account management. New users are added within the DevArmor application by your organization's DevArmor admin, or by contacting `support@devarmor.com`.
### Configuration steps (OneLogin administrator)
For general background on adding apps in OneLogin, see OneLogin's own [Introduction to App Management](https://docs.oneidentity.com/bundle/onelogin_administration-portal/page/guides/administrationportal/introduction-to-app-management.htm#adding_apps_d71e238) guide.
1. In the OneLogin admin portal, go to **Applications → Applications → Add App**.
2. Search for **"DevArmor OIDC"** and select it, then click **Save**.
3. Open the **SSO** tab and copy the **Client ID** and **Client Secret**. The redirect URI and Token Endpoint Authentication Method are pre-configured by the connector — unlike the generic OIDC setup, there's nothing to set manually here.
4. On the **Users** tab, assign the users who should have DevArmor access.
5. Send DevArmor the following (see [our guide for a secure transfer](/getting-started/single-sign-on-sso-authentication/encrypting-credentials-for-devarmor) for the client secret):
* Your **OneLogin domain** (for example, `yourcompany.onelogin.com`, or your custom domain if you use one)
* The **Client ID** and **Client Secret** from step 3
* The **email domain(s)** your users sign in with (for example, `yourcompany.com`)
6. DevArmor enables SSO routing for your organization and confirms by email.
### SP-initiated SSO (end users)
1. From your browser, navigate to the DevArmor sign-in page at [**https://app.devarmor.com/sign-in**](https://app.devarmor.com/sign-in).
2. Click **Sign in with OneLogin** and enter your work email address.
3. You're redirected to your OneLogin organization to authenticate with your OneLogin credentials.
4. After successful authentication, you're redirected to the DevArmor dashboard.
### Adding new users after setup
The same two-step process applies whether DevArmor was added via the catalog or the generic OIDC connector — see [Adding new users after setup](/getting-started/single-sign-on-sso-authentication/onelogin-sso-manual#adding-new-users-after-setup) on the manual setup page (just substitute **DevArmor OIDC** for the app name in that guide's OneLogin-side step, matching whatever you named it in step 2 above).
### Support
* **Support email:**
* **Documentation:** [https://docs.devarmor.com](https://docs.devarmor.com/)
# OneLogin SSO (Manual)
### Setting up DevArmor SSO with your OneLogin
DevArmor supports signing in with your organization's OneLogin via OpenID Connect. Your OneLogin administrator needs to register an app and share four values with us. Time required: \~10 minutes.
DevArmor also has a dedicated connector in OneLogin's App Catalog, which pre-configures the redirect URI and token settings for you — see [OneLogin SSO (App Catalog)](/getting-started/single-sign-on-sso-authentication/onelogin-sso-catalog) if that's available in your org. Use this manual setup with the generic OIDC connector if it isn't, or if you'd rather configure everything yourself.
### Supported features
* **SP-initiated SSO**: users start sign-in from the DevArmor application.
Not supported:
* IdP-initiated SSO (launching DevArmor from the OneLogin portal). Sign-in always starts at `app.devarmor.com`
* Just-in-Time (JIT) provisioning. DevArmor provisions users on its side; authenticating via OneLogin doesn't create a DevArmor account by itself. See [Adding new users after setup](#adding-new-users-after-setup) below.
* SCIM provisioning
* Single Logout (SLO)
There's currently no public API for account management. New users are added within the DevArmor application by your organization's DevArmor admin, or by contacting `support@devarmor.com`.
**Step 1 — Create an OIDC app in your OneLogin org**
* OneLogin Admin Console → **Applications → Add App**
* Search for **"OpenId Connect (OIDC)"** and select it *(the generic connector — DevArmor isn't in the OneLogin app catalog yet, so there's no dedicated "DevArmor" listing to search for)*
* **Display name:** `DevArmor`
* **Configuration tab → Redirect URI:** `https://auth.devarmor.com/oauth2/idpresponse`
* Leave **Login URL** blank — sign-in always starts from DevArmor, not from your OneLogin portal
* **Users tab:** assign the users who should have DevArmor access *(not the Access tab — that's for role/policy-based rules; individual and ongoing user assignment happens under Users)*
**Step 2 — Set the Token Endpoint Authentication Method to POST**
On the app's **SSO tab**:
* **Application Type:** `Web`
* **Token Endpoint Authentication Method:** **`POST`**
**Step 3 — Send DevArmor these four values**
*(please send the client secret over a secure channel — a password manager, encrypted message, or our* [*PGP key*](/getting-started/single-sign-on-sso-authentication/encrypting-credentials-for-devarmor) *— not plain email)*:
1. **OneLogin domain** — e.g. `your_domain.onelogin.com`, or your custom domain if you use one
2. **Client ID** *(from the app's SSO tab)*
3. **Client Secret** *(from the app's SSO tab)*
4. **Email domain(s)** your team uses — e.g. `your_domain.com`
We'll enable routing for your domain. Your team then signs in at **`app.devarmor.com`** → **"Sign in with OneLogin"** → enter their `@your_domain.com` email → they're redirected to your OneLogin to authenticate.
### Adding new users after setup
DevArmor doesn't support Just-in-Time provisioning, so there are **two separate steps** for every new user.
1. **In DevArmor**: an account must exist for the user (matching email address). Your organization's DevArmor admins can add this from within the app from **Members** tab, or contact `support@devarmor.com`.
2. **In OneLogin**: your OneLogin admin must assign the user to the DevArmor app on its **Users** tab (Applications → DevArmor → Users → add the user).
**Troubleshooting adding new users**
* Missing either step causes sign-in to fail.
* If step 2 is missing, the user is bounced back before ever reaching a DevArmor screen, usually with `error=access_denied` and `error_description=End-user does not have access to this application` visible in the URL.
* If step 1 is missing, the user successfully authenticates via OneLogin but is rejected by DevArmor as unrecognized. This is indicated by a red toast message `User not authorized`.
### Notes
* You keep full control of your own MFA and sign-on policies. DevArmor never changes them.
* Organizational (work) OneLogin accounts only; personal accounts aren't supported.
# Encrypting Credentials for DevArmor
## Encrypting credentials for DevArmor (PGP)
When you send DevArmor sensitive values, for example, your Okta **Client Secret** when enabling SSO, encrypt them to our PGP public key first so they're never transmitted in plaintext.
### Our public key
* **Identity:** `DevArmor Integrations `
* **Fingerprint** (verify this matches before you trust the key): `54DC 69B7 9814 3F17 DE9A 8C4E 86CF 68A8 35EB 2EC0`
Public key block:
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGo1baUBEADU6+UGd6s3l1J3dv6eUYkAtayT8GQLR6GMFDZdwrOECNcKBQUm
QiH2JT5f6OCRWiLNfFx5Mc0zSHhBRRrMJHnwSo368kRycMZ5GsnPxIRiseRsKBze
nfHE4o80mAl8pjGkrWhLrJ65rrchDu4BkmdAkBO3tuRNtHZvQaYsFbkBGY2dDIXu
j+3HMw2BZCIJoFRpfvIzi0nFBpR4craSpfj0jprFmc0va6ibXUE7KF2kBLIMTQBt
Ydoh03xXsYUopRclbabV6/G+2sWp7Mhh23lTpRXXdrS8zaoHxGbI6CGRLXym+7+m
xMzk5m/WyfFjIn+d/BhaJp1kwhJrmPOFyKegGABBun3MxlPFGI/LBBGWpEIFm4UN
f0HT0bgUFM7c1oNxn6eJDnDczGOHjFI+Fr2S0J1J18u4sUQfuF6T0xMbfkcj9Di/
Jlz/S+b0C3wKxFkSSY4scKjzZmPXOS71iltCWRn2yDuUzNiOfRQ6YvUqcGUgxs9O
WOhRGWroLKAJzprHIXIe+swagKfFldm7M0qet2/OWmNA6/1s5JqS4uMfq1jACqO0
uP4MAQ+ZjBMa52U/K226Hqac/kN1yDcKo34Q3IbJVMe/h0EuiJM7gd6KBLxftjgp
YmxmUEUz2iime6t0olNjRrZjwXexyx/8I4HgaS2LYXBEOjsjv7iWoZnK5QARAQAB
tDFEZXZBcm1vciBJbnRlZ3JhdGlvbnMgPGludGVncmF0aW9uc0BkZXZhcm1vci5j
b20+iQJYBBMBCABCFiEEVNxpt5gUPxfemoxOhs9oqDXrLsAFAmo1baUDGy8EBQkD
wmcABQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEIbPaKg16y7A7vMP/0yO
uHdkN5ciwYi1aWO1yxRywEEyYQHrJSco+0B+y218+M2IRBIkNuR6sfqo/Th04VpL
ynsaAm8hwc4/RumgFCUCD+IqoXF5PpRrAOqm24muqOCRqw4jnx2Y/MvpF2AdUbKL
TIV3tG+mS0yP+PsuvO8JVHt2Fykx1LOPIlciBlcxiYwCqjpLG0+wQniPc+BNBR3/
Eh52hwUXXS7boi0AMzun8bRYCtq5f4Etlul7qWJA2c06waHGePWb0pXA/IvgpLhN
oYNTmFChuNjanYr9BETi0lj7h/+wCC2N/ZOMnqyqC+lbwtVBNs8f7p23SU7GoYKm
JShyP4HXlCoywt7UVxoLtsCqQ0QR4RVsUPUtGKy159tJMvd1F+b0WaoQMZ8eANBY
5nG9of67mtino8V8zoK0XuvvwGEm2mwSapLbMgnf8MrWJeny1/Teb8Y4v9KKW2HU
tpgp20i4awo1YYLl8y5nWzUgi2NtVD3FWuC6NRHdbit/luKeamJpnXBsDw5M6rOw
plwGoDPVzTqtHqpfapF5Hpltgcjdzy6ucvQHZTHfhZ6B9sT20+hkYKwe7pKp3HTV
XrYhuR1ydBYeThqHMNfKnJWxb8EFDZ1acdv4BE4WAxzVtszxI2YRlDKPyFbT3RD4
LwtXot/h5/w48EuFpZPKQkd4kmnNcQEPBUHG3DhauQINBGo1baUBEAClG9Gjv6A3
bnYUZdOmUdXbZGZBgy4sXApo2SvjsFFPllk1J5Gre0xL+TTT/y1EpTo5b4zosPa2
tmd9AeNnkYYgwEguT9S9IBmPNnW90Yb/qWTIqFRvsgchv/Nqc80GT/H2M+wVT/DP
sfqTdLCGUYWoz9hv14yKq+bJ+olwbPbMGWD0qyH7CgWkbMU77rukK1GDqNDTVBXc
vBCjX2tuHivYfeuc6QFzwRpJaz08Zpy61b1Kl2BxD0hchy5Ud06D3WK1s2NdeyDi
UHGlqOH4nVOjub974aN/SN5bgvGj206ka1Bm2ybG3r0px4zXUddY4kibLsFiPHL1
yPbNE/e3RSuBn92YMjtvHL4hmmyY9UrC0BsGmVHTq4xraQ2BlxzWBShHF2/xYdWE
DgUXYZ4l53TRHHvcL9aV+ptjja5sDcnrKOX72uZCz7oFiqXb5ErQGC57sOESr24J
SQpEYfHtWmK8TQD9rXKVBbC6OFiHmaw801bEzb2uYyo13eOUTmZc1yQyxq/HflJm
6fRujuEAXe/Ejn68hCu6lNYOIFsrv/1v/syBqZPmlqqvozNjdGSBn7w11vVvKoUd
O9uY7n3PE2MrLZxrSUOY4s5d6DFinEDoK89XTXcAf6Fs4TbkuI7F/u9EoOKG9ziw
9nyfrkEPIhDlzneXBhy/Kgezi5a+ZhbBGwARAQABiQRyBBgBCAAmFiEEVNxpt5gU
PxfemoxOhs9oqDXrLsAFAmo1baUCGy4FCQPCZwACQAkQhs9oqDXrLsDBdCAEGQEI
AB0WIQSyVcN6gEqfzPpeQKxuVxlCcLmlaAUCajVtpQAKCRBuVxlCcLmlaGVpD/0a
hBNf7Som3376IBFatH+qyyIZXF/uyTwcgHsn3vA63lBqIKGAdhzYQc+oDr0/efID
hm4Oi7jk/O1WuFxUCffvqt+Hn1P2Xrmq+B2OYhIUz3C7SwnyOybnO6+2zbrr/1cS
VwkGRkVeGSW4FRaEH/s+LtWErbBgBtAPOf8AwvI38FFmMt6wULdJnhUkksljfDHo
R1uj92B4InBS7+iqjaURuzoKF6PnbufVJfLyszSQnL8myuAbNbiA0P/yVyjT/1h7
30JatL2/UMa79lxzhvg0ldafHUAm9IfjMmwtB5YPFjee1wiuwqVV06wi6BoJBpAC
ZhSKErkX3y01SvE6Rc26sMtYdXmxwPFyxT4AAVPm2sEpCWDVteookrtf0DiK0fLg
02um0ypMiXV9LoPsIhjAI3smEr36q5XArkSszVQyZOo3phnIpewcZqdRY87SMQXk
CfG0burjHalDbpoAwWo67RuyP73nTNv96PjDsYNRTIWWQUCgMN4avAXZk/DBl8+u
k5F+XQcbeEM1/N1SNbvH/qXAM0cCmaTvpqlt3jvDLCBPQDIHehjSiAyE03KswXMK
cEmeity8URbpYta3R9Fm1XdVMuNr6bYEOvnIe35eGy3+J3Sr/sdvcBfU+8QG2Ai/
B5DiK4hsWxQAu+RvZQ/83VjBY0KR6eYGEFSG88qlFV1gD/9fU9QNm5v/pqDUQydc
ZFPfdSgJh5muj7qy6r2a4W3NghbQOPXkhjRi70KC8ulTEG3uHidiec6r7jSOzRLD
lVypX6zoFHlBtHzaSzG7owm/q0ebopBIxocvRCPfFowdjdgZmEqt0w/Kfs6ZGy+R
HqFxpFpiqZgVj2EiLsJdxvadSAsxv0MOW2BwrobjtH2zSkMmDsErEqU7vaVFwHwn
GR4BXfhHCGjQWitIqsSH1VaO1PwiDMry/Sh33UvqqL/PiS8PavD1hyxWkV29jfkx
c11JpbIFs+pORXAAMqB+zKCAtjH7ieJqEY0WD9flcqciBPbalPMPTVB/DlaQUH/T
H4zLpolQchbcVSYbLRbdpquQ/92RU0YVCRD3xTYJ0H3Zzi9vUpfqjTBHqZ4pxwwJ
l8r7b45I+a8MdpAXfOt0vnq40GZHrWS2F6Bwlh48+Cvd0vXbZK5NRlwdF6pXSJnr
S5AYtIlAg5hRs8z2kDi/aJ0HocsiMFHQSib83Sy8MNC4YpH4t/vGdEeLb/ijF6om
AgL+DRSdZo9kUl1Jzi+4lOV54H2jpEomYf0CyNssIKbmCFNwuBxHu02vTJZUZ0p3
sFmeSNeJA1MlYRwC3goBJiTCc0du9O67YwTGuK7NxX26+hsLoA8tABO2CNNuNhwS
v5c2sPCZF+qSvdgHTo4/5XmtCQ==
=Xh+O
-----END PGP PUBLIC KEY BLOCK-----
```
### How to encrypt and send
Using the GPG command line:
1. Save the public key block above to a file (e.g. `devarmor-integrations.asc`) and import it:
```sh
gpg --import devarmor-integrations.asc
```
2. Confirm the fingerprint matches the one listed above:
```sh
gpg --fingerprint integrations@devarmor.com
```
3. Put your Okta **org domain, Client ID, and Client Secret** in a file (e.g. `creds.txt`) and encrypt it:
```sh
gpg --encrypt --armor --recipient integrations@devarmor.com creds.txt
```
This produces `creds.txt.asc`.
4. Email **`creds.txt.asc`** to ****. We enable SSO routing for your organization and confirm by email.
Prefer a GUI? [GPG Suite](https://gpgtools.org/) (macOS) or [Kleopatra](https://www.openpgp.org/software/kleopatra/) (Windows/Linux) can import the key and encrypt with a few clicks.
# GitHub Integration
## Overview
DevArmor connects to your GitHub Enterprise instance through a dedicated agent that monitors pull requests, posts security review findings, and syncs Code Review results back to your repositories. For this communication to work, your GHE tenant must permit inbound and outbound traffic from DevArmor's IP address.
Most GitHub Enterprise deployments restrict network access to a set of known IPs. Adding DevArmor's IP to your allowlist ensures uninterrupted connectivity between the agent and your repositories.
## How It Works
1. Retrieve DevArmor's static IP address from the table below.
2. Add the IP to your GitHub Enterprise allowlist (Settings → IP Allow List).
3. DevArmor's agent begins communicating with your GHE tenant — no restart or additional configuration required.
```mermaid
sequenceDiagram
participant Admin as GHE Admin
participant GHE as GitHub Enterprise
participant DA as DevArmor Agent
Admin->>GHE: Add DevArmor IP to allowlist
DA->>GHE: Connect to repositories
GHE-->>DA: Permit traffic
DA->>GHE: Post review findings to PRs
```
*DevArmor's agent connects to your GHE tenant after the IP is allowlisted. No additional authentication changes are needed.*
## Installation
Install the DevArmor GitHub App on your organization:
1. Navigate to [github.com/apps/devarmor](https://github.com/apps/devarmor).
2. Click **Install**.
3. Select the GitHub organization you want to connect to DevArmor.
4. Choose repository access — grant access to **All repositories** or select specific repositories for DevArmor to monitor.
5. Click **Install** to confirm.
Once installed, DevArmor receives webhook events from your repositories and can post Code Review findings directly to pull requests.
### GitHub Enterprise IP Allowlisting
DevArmor's GitHub agent requires network access to your GitHub Enterprise (GHE) tenant. This page covers how to allowlist DevArmor's IP address so the agent can communicate with your environment.
### DevArmor IP Address
| Environment | IP Address |
| ----------- | --------------- |
| Production | `52.12.139.131` |
### Prerequisites
* Admin access to your GitHub Enterprise instance
* DevArmor GitHub integration enabled in your DevArmor workspace
### Configuration
#### Adding the IP in GitHub Enterprise
1. Navigate to your GitHub Enterprise **Settings → IP Allow List**.
2. Click **Add IP address**.
3. Enter `52.12.139.131`.
4. Add a description (e.g., "DevArmor Agent").
5. Save the entry.
> **Note:** If your organization uses an additional network firewall or proxy in front of GHE, you may also need to allowlist this IP at the network level. Consult your infrastructure team if the agent fails to connect after updating the GHE allowlist.
# Atlassian Integration
## Overview
DevArmor connects to your Atlassian site to read *Jira* tasks and *Confluence* pages in the context of threat model or design review workflows, and to push DevArmor tasks to *Jira* or link them to existing *Jira* tasks.
DevArmor's Atlassian integration requires installing our Atlassian *Forge* application.
## Installing the Integration
When you install the Atlassian integration for the first time from the [*Integrations*](https://app.devarmor.com/integrations) page, Atlassian asks you to select the Atlassian site (if you have more than one), grant the necessary permissions, and offers you to select the Atlassian app "connections". The *Jira* connection is required, and the *Confluence* connection is optional.
## Upgrading the Integration
From time to time DevArmor releases new versions of the Atlassian application. In this case you will see an outdated app in your Atlassian site's listing of installed apps. Go to the [Atlassian Admin Console](https://admin.atlassian.com/) and click **Apps → Sites → (your site) → Connected apps**:
Note the `Update` chip next to the *DevArmor* app. Click **View app details** in the *Actions* column:
Now click on the blue `Update` button at the top right corner of the page. This will open a dialog explaining the new capabilities offered and new permissions required. Click the `Accept & Update` button. After 5–10 seconds of processing, the latest version of the DevArmor app will be installed in your Atlassian site:
The app is always connected to *Jira*, however we have recently added support for *Confluence*, and if you did not previously connect the app to *Confluence*, you can do this by clicking the `Manage connections` button in the **CONNECTED TO** section.
This concludes the process for updating the DevArmor app in your Atlassian site. It can take up to 5 minutes for new permissions to propagate to our system and new functionality to be enabled.
# Modules
DevArmor's product modules, and how they work together.
DevArmor is made up of three modules that share the same underlying threat model:
* [**Threat Modeler**](/modules/threat-modeler) — builds and maintains a model of your application's architecture, threats, risks, and controls.
* [**Design Reviewer**](/modules/design-reviewer) — checks a specific ticket, document, or diagram against that threat model before implementation begins.
* [**Code Reviewer**](/modules/code-reviewer) — enforces the resulting security requirements and controls on every pull request, and can turn them into rules for AI coding assistants.
Because all three modules read from the same threat model, a control identified during threat modeling shows up again during design review, and is enforced again during code review — without re-entering it three times.
# Threat Modeler
How to do threat modeling with DevArmor
DevArmor's Threat Modeler turns a description of your application, architecture, or feature into a structured threat model: the trust boundaries and components at risk, the threats that apply to them, and the controls and tasks needed to mitigate those threats.
A threat model moves through five stages:
1. [**Starting a threat model**](/modules/threat-modeler/starting-a-threat-model) — import an existing threat model, or describe your application from code, documents, and diagrams.
2. [**Verify Application Attributes**](/modules/threat-modeler/verify-application-attributes) — review and correct what DevArmor inferred about your application before analysis runs.
3. [**Architecture & Diagrams**](/modules/threat-modeler/architecture-and-diagrams) — DevArmor's view of your system: components, data flows, and trust boundaries.
4. [**Review Threat Model Output**](/modules/threat-modeler/review-threat-model-output) — the threats, risks, and controls DevArmor identified.
5. [**Implement Threat Model Results**](/modules/threat-modeler/implement-threat-model-results) — turn output into mitigation actions, tests, and tasks in your existing tools.
See [Data Model Hierarchy](/modules/threat-modeler/data-model-hierarchy) for how threat models relate to projects, teams, and your organization; [Threat Model Versions](/modules/threat-modeler/threat-model-versions) for iterating on a threat model over time; and [Reports & Exports](/modules/threat-modeler/reports-and-exports) for sharing results outside DevArmor.
You can also build and review Threat Models directly from your editor — see the [VS Code / Cursor Extension](/modules/threat-modeler/vs-code-extension).
# Threat Modeler Overview
An overview of DevArmor's Threat Modeler
Threat Modeler is DevArmor's core module for identifying security risks in an application. It combines information from your code repositories, architecture diagrams, and documents (PRDs, release docs, vulnerability reports, SAST/CSPM output) into a single model of your system, then analyzes that model for the threats, risks, and controls relevant to it.
A threat model captures:
* **Architecture** — the components, data stores, data flows, actors, and trust zones/boundaries that make up the system. See [Architecture & Diagrams](/modules/threat-modeler/architecture-and-diagrams).
* **Threats** — specific ways the system could be attacked, categorized using the industry-standard STRIDE framework and mapped to MITRE ATT\&CK techniques and tactics for deeper context.
* **Risks** — the business impact of a threat being realized, scored consistently using a defined formula.
* **Controls** — the mitigations that reduce a risk, which can be mapped to relevant compliance requirements and frameworks.
Watch a short walkthrough:
{% embed url="" %}
# Data Model Hierarchy
Understand how DevArmor organizes and isolates threat model data across different teams and projects.
The purpose of this document is to clarify the hierarchy of our product data isolation and management. In particular, we cover use cases and workflows to manage threat models and security reviews in organizations based on their size, team composition, and workflows.
## Data Hierarchy
### Organization
Organization (“Org”) is the highest level of abstraction in DevArmor’s data model. Org usually correlates to the company as a whole, or a single **unit of risk management**. One way to think about Org is that there is usually one Org per CISO.
### Team
A Team is a unit of organization that prioritizes security actions and decisions together. Different teams can share some risks together, or have totally separate risks. The key concept that ties a team together is **planning and prioritization**. A Team roughly corresponds to a unit of organization under a VP or Director of Security.
A single organization can have many teams.
### Project
A Project is an abstraction layer that corresponds to a product, feature, or service within an organization. A project usually corresponds to a unit of **product development and release schedule**. Alternatively, one can think of a project as a unit of engineering work or organization, such as an engineering team.
A single team can have many projects.
### Threat Model
A threat model is the lowest level of abstraction in this model, and represents a single body of analysis of risks, threats, mitigation plans, and actors for the project as a whole.
A project can have multiple threat models, and each threat model can have multiple [versions](/modules/threat-modeler/threat-model-versions).
### Design Review
A design review lives alongside a project's threat models, but is scoped to a single change — a Jira ticket, document, or diagram — rather than the whole system. See [Design Reviewer](/modules/design-reviewer).
## Data Isolation
DevArmor supports sharing security and product context across projects and teams. This will be set at the Org level.
# Starting a threat model
How to start a threat model
There are several ways to start a threat model, and you can combine them — DevArmor merges everything you provide into one coherent view of your application:
* Import an existing threat model
* Connect a code repository
* Import supporting documents and tickets
* Describe the application and its attributes manually
## Import an existing threat model
You can import an existing threat model in a JSON format into DevArmor's web application.
From the first page, click on "Import" and then upload your JSON file into DevArmor.
Here is an example of a JSON file representation of a threat model.
{% file src="/files/YYgZCvUokWjujAqpqxVE" %}
## Connect a code repository
Linking a GitHub repository lets DevArmor generate architecture directly from your code, and lets [Code Reviewer](/modules/code-reviewer) apply your policies to every pull request. You can scope analysis to a specific subfolder instead of the whole repository, and link multiple repositories to a single threat model to model how they connect as one system.
## Import existing documentation
You can import existing documentation and tickets to provide more context for the threat model. Supported sources include:
* Product Requirement Documents (PRDs) and release documents
* Vulnerability reports, CSPM outputs, and SAST outputs
* Architecture diagrams — including photos or scans, which DevArmor converts into an editable digital diagram automatically
* Confluence pages
* Google Docs
* Jira tasks and epics
* GitHub Wiki pages
To import documents, from the "Describe" section, select "Upload" and then upload documents.
## Describe and decompose the application
If you don't have existing documentation to import, or want to add context beyond what's in your documents and code, you can describe your application directly in the "Describe" section: what it does, who its users are, what data it handles, and how it's built. DevArmor uses this description alongside anything else you've connected — repositories, documents, diagrams — to decompose the application into components, data flows, and trust boundaries before generating its architecture.
Once DevArmor has decomposed your inputs, move on to [Verify Application Attributes](/modules/threat-modeler/verify-application-attributes) to review what it inferred.
# Verify Application Attributes
After describing the application, you can review and validate threat model inputs
After providing the initial inputs to the threat model, DevArmor distills specific information that is required to perform a threat model. In the "Decompose" tab, you can review this information, make any changes, and approve them.
This typically includes attributes like:
* Business criticality and data sensitivity of the application and its data
* Authentication and access-control methods in use
* The actors (users, services, external systems) that interact with the application
Correcting an attribute here is much faster than correcting it after DevArmor has generated architecture and findings from it — this step exists so a wrong assumption doesn't propagate through the rest of the threat model.
Once you approve these attributes, DevArmor generates the application's [architecture](/modules/threat-modeler/architecture-and-diagrams) and moves on to identifying threats.
# Architecture & Diagrams
How DevArmor builds and maintains your application's architecture
DevArmor combines everything you've connected — code, uploaded diagrams, and documents — into one coherent architecture: the components, data stores, data flows, actors, and trust zones/boundaries that make up your system.
## Generating architecture
Architecture can be generated from any combination of:
* **Code** — analyzing one or more linked repositories, modeling how multiple repositories connect as a single system when more than one is linked.
* **Diagrams** — uploaded architecture or data-flow diagrams, including PDFs, photos, or scans of a whiteboard, which DevArmor converts into an editable digital diagram.
* **Documents** — PRDs, release docs, and other imported documentation; architecture generation takes diagrams and visuals within a document into account, not just its text.
You can generate architecture at the project level, covering everything linked to the project, or within a single threat model version. When creating a new threat model version, you can choose to reuse the architecture from the version it's based on instead of regenerating it.
Trust boundaries are generated automatically as part of this process.
## Reviewing and editing diagrams
Generated diagrams are Mermaid diagrams you can edit directly: zoom, pan, and click between the diagram and the table row for the component, data store, or data flow it represents. Diagrams also display trust-zone information for their elements, with clickable references to related items.
## Data source coverage
Architecture generation works even for repositories without a GitHub integration installed, falling back to public access where possible.
# Review Threat Model Output
Review and approve threats, risks, controls, and other threat model outputs.
Once the threat model is generated, you can review the threats, risks, and mitigation plans (including controls) that DevArmor has suggested.
In the "Output" step, you can make any changes to the threat model output.
## Threats
Every identified threat is categorized using the industry-standard **STRIDE** framework: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
Threats also show related **MITRE ATT\&CK** techniques and tactics for deeper context, and indicate which architecture components they affect.
## Risks
Each threat is associated with one or more risks — the business impact of the threat being realized. Risk scores and severity levels are calculated consistently using a defined formula, so risk ranking is comparable across threat models.
## Controls
Controls are the mitigations that address a risk. A control can be mapped to multiple relevant compliance requirements — browse the complete list of supported compliance controls and frameworks when mapping a control, not just ones already in use.
## Comparing versions
Use the Version Diff view to compare two versions of a threat model side-by-side and see exactly which threats, controls, and risks changed. See [Threat Model Versions](/modules/threat-modeler/threat-model-versions).
Once you've reviewed and approved output, move on to [Implement Threat Model Results](/modules/threat-modeler/implement-threat-model-results).
# Threat Model Versions
Iterate on a threat model over time, and compare versions.
A threat model isn't a one-time snapshot — a project's architecture and risk profile change as the application evolves, and DevArmor tracks that as new **versions** of the same threat model.
A project can contain multiple threat models, and each threat model can have multiple versions.
## Creating a new version
When you create a new version of a threat model, you can:
* Reuse the architecture from the version it's based on, instead of regenerating it from scratch.
* Carry over its description automatically.
* Manage which code repositories are linked to that specific version — repositories linked to a project are shared across its threat-model versions rather than duplicated per version.
## Comparing versions
The **Version Diff** view compares two versions of a threat model side-by-side, showing exactly which threats, controls, and risks changed between them — useful for confirming a change actually reduced risk, or for reviewing what a redesign introduced.
## Deleting
You can delete a single version of a threat model, or delete an entire threat model (all of its versions) at once. If a resource you're trying to delete has other items depending on it, DevArmor tells you exactly what those dependent items are before you proceed.
# Implement Threat Model Results
How to operationalize threat model outputs
At the last step, you can operationalize the threat model outputs. At this step, you can review security requirements, actions, tests, and other tasks that were deemed relevant as a result of the threat modeling.
We group these downstream activities into four groups:
* **Mitigation Actions**: Tasks that need to be performed by security or engineering teams. You can push these directly to your issue tracking platform — pushing to Jira includes a link back to view the task in Jira, and respects your organization's required custom fields and issue types.
* **Automated Tests**: Tests DevArmor can run automatically in GitHub. These act as policies enforced by [Code Review](/modules/code-reviewer), and can also be turned into [AI Guardrails](/modules/code-reviewer/ai-guardrails) rule files for AI coding assistants.
* **Manual Tests**: Tests that cannot be run automatically and need to be run manually by your team.
* **Penetration Tests**: Scopes that can be pushed to bug bounty programs or penetration testing consultants, each specifying exactly which system component it targets.
# Reports & Exports
Share threat model results outside DevArmor.
DevArmor generates reports from a threat model's output for sharing with stakeholders who don't use DevArmor directly.
## Threat Model Analysis Report
The core report includes:
* An AI-generated executive summary
* Summary statistics — documents and diagrams reviewed, threats/controls/risks identified
* A system architecture diagram
* An optional generated Privacy Impact Assessment
Report tables let you show, hide, reorder, and resize columns and rows, and the report has a collapsible summary with a copy-to-clipboard button so you can show or hide individual sections.
## Attack Surface Analysis
Attack Surface Analysis translates identified threats into a prioritized, ready-to-work set of engineering tasks, drawing on MITRE ATT\&CK mapping and compliance control mapping.
## Exporting
Reports can be:
* Downloaded as a PDF, generated and exported directly from a project without needing to reference a specific version.
* Exported to Google Docs, with control over which Google Drive folder they're saved to.
## Report gallery
The Report gallery lists every generated report artifact for a project, available from the dedicated Reports tab in Settings.
# VS Code / Cursor Extension
Work with Threat Models next to your code in VS Code or Cursor.
DevArmor's VS Code extension (also works in Cursor) brings Threat Models into your editor: sign in, pick a project, and review threats and controls in a sidebar next to your code — with open controls published to the editor's Problems panel.
### What it does
* **Sign in** through the DevArmor web app (OAuth). Tokens are stored in the editor and refreshed automatically.
* **Pick a project** — choose an existing DevArmor project or create a new one. The current project is shown in the status bar.
* **Threat Model sidebar** — after a project is selected, the Activity Bar icon opens a Threat Model view with **Threats** and **Controls** sections. Threats are sorted by name; controls are grouped by priority (Critical → None).
* **Build** — prepare a Threat Model (name, documents, repos), create a version, and run a findings scan. Repositories are checked against the API; ones you can't access are marked in the setup UI.
* **Load results** — pick an existing Threat Model and version from the project and fill the sidebar without running a new build.
* **Finding details** — click a threat or control to open a detail view. Threat details include event, STRIDE category, sources, target components, frameworks, persona, and associated controls. Both link back to the matching finding in DevArmor.
* **Problems panel** — controls that aren't done are published as diagnostics under source `DevArmor`. Severity follows control priority: Critical/High → Error, Medium → Warning, Low/None → Information.
* **Status bar** — shows the current project and, once a scan has run, the finding count.
One workspace folder keeps at most one active Threat Model + version at a time.
### Installation
DevArmor's extension isn't on the public VS Code Marketplace yet — install it from the `.vsix` file DevArmor provides:
1. Get the current `.vsix` build from your DevArmor contact.
2. In VS Code or Cursor, open the Command Palette and run **Extensions: Install from VSIX...**, then select the file.
3. Reload the editor if prompted.
### Using the extension
1. **Open the DevArmor view** — click the DevArmor icon in the Activity Bar, or run **View: Show DevArmor** from the Command Palette.
2. **Sign in** — if you're not signed in, the view shows **Sign in to DevArmor**, which opens the DevArmor app in your browser; sign-in completes there and returns to the editor automatically. You can also run **DevArmor: Sign In**.
3. **Pick a project** — after signing in, choose an existing project or create a new one (**DevArmor: Open a Project**, the sidebar button, or the status bar item). You can't change projects while a build is running.
4. **Get findings into the sidebar**:
* **Run Threat Model** (the **+** button) opens the setup view. Create a new Threat Model, or a new minor version of an existing one — attach documents and select workspace git repositories, then DevArmor runs architecture, findings, and action-item generation. Threats and controls land in the sidebar once findings complete.
* **Open Threat Model** lists Threat Models in the project; choosing a version loads its threats and controls into the sidebar without running a new build.
5. **Review findings** — expand **Threats** or **Controls** in the sidebar, or click a matching entry in the Problems panel, to open its detail view.
6. **Sign out** — **DevArmor: Sign Out** clears stored tokens.
### Commands
Open the Command Palette (`Cmd+Shift+P` / `Ctrl+Shift+P`) and type `DevArmor`:
| Command | What it does |
| ------------------------------- | ------------------------------------------------------------------------------------------------- |
| **DevArmor: Sign In** | Starts browser sign-in if you're not already authenticated. |
| **DevArmor: Sign Out** | Clears stored auth tokens. |
| **DevArmor: Open a Project** | Opens the project picker (create or select). Disabled while a build is running. |
| **DevArmor: Run Threat Model** | Opens the Threat Model setup view (new model or new minor version), then runs the findings build. |
| **DevArmor: Open Threat Model** | Picks a Threat Model version from the project and fills the sidebar. |
| **DevArmor: Show Output Logs** | Opens the DevArmor Output channel (API calls, auth, builds) — useful for troubleshooting. |
### Settings
Open **Settings** and search for `DevArmor`.
| Setting | Default | Description |
| ------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `devarmor.logLevel` | `info` | Verbosity of the DevArmor Output channel. `debug` includes request start lines; `warn`/`error` show only higher-severity events. |
# Design Reviewer
Run automated security design reviews on tickets, documents, and diagrams before implementation begins.
DevArmor's Design Reviewer evaluates a specific piece of upcoming work — a Jira ticket, a design doc, an uploaded diagram — against your organization's threat model, and surfaces the security requirements, potential issues, and recommended controls it should satisfy before implementation begins.
Where [Threat Modeler](/modules/threat-modeler) analyzes your application as a whole, Design Reviewer analyzes one change to it — so security feedback reaches engineers at planning time, not after the fact, without security having to manually triage every ticket.
## Starting a design review
A design review can be created from:
* [**Jira**](/modules/design-reviewer/jira-integration-security-design-review) — automatically, for every new ticket in a monitored project, or on demand from the DevArmor panel on an issue.
* [**Confluence pages, Google Docs, and GitHub Wiki pages**](/modules/design-reviewer/creating-a-design-review) — imported as the source document for the review.
* **Uploaded diagrams** — DevArmor automatically interprets uploaded architecture and data-flow diagrams as part of the review.
* The [**Google Docs Add-on**](/modules/design-reviewer/google-docs-add-on), directly from within a document.
## Review output
See [Review Output & Findings](/modules/design-reviewer/review-output-and-findings) for what a completed design review contains: potential security issues, security requirements, abuse cases, and more.
# Creating a Design Review
Ways to start a design review outside of Jira.
In addition to the [Jira integration](/modules/design-reviewer/jira-integration-security-design-review), you can start a design review directly from documents and diagrams.
## From a document
Design reviews can be created from:
* Confluence pages
* Google Docs — including directly from within the [Google Docs Add-on](/modules/design-reviewer/google-docs-add-on), matching the existing threat-model workflow
* GitHub Wiki pages
To use a pasted URL instead of browsing for a page, DevArmor can resolve a pasted Confluence or GitHub Wiki URL directly to the matching page.
## From diagrams
DevArmor automatically interprets uploaded architecture and data-flow diagrams as part of a design review, and takes any diagrams uploaded previously into account when generating recommendations.
## Custom rules
You can create and manage custom rules that guide DevArmor's automated design reviews, in addition to the standard analysis against your organization's threat model.
## Memory
Design reviews use your organization's connected memory sources — Confluence pages, Google Docs, and Jira issues you've attached to the project — the same shared organizational context available to Threat Modeler. You can turn memory use on or off per design review from project settings, and DevArmor shows whether memory was actually used for a given review, with an explanation when it wasn't.
Once a review completes, see [Review Output & Findings](/modules/design-reviewer/review-output-and-findings).
# Google Docs Add-on
Run security design reviews on a Google Doc without leaving it, using the DevArmor Google Workspace Add-on.
### Overview
The DevArmor Google Workspace Add-on brings design reviews into Google Docs. Open the add-on from a doc, pick or create a DevArmor project, and run a security design review on the document's contents — findings and requirements show up right there in the sidebar, without leaving Google Docs.
### Integration Type
DevArmor is published on the **Google Workspace Marketplace** as a Workspace Add-on (a CardService-based sidebar), not an Editor Add-on. It's installed like any other Workspace Marketplace app — by a Workspace admin for the whole domain, or by an individual user for themselves.
**Permissions requested at install:**
* Read/write access to the currently open document only (Google's `drive.file` scope — DevArmor never sees other files in your Drive)
* Your email address, to match you to your DevArmor organization
* Permission to call the DevArmor API from within the add-on
### How It Works
DevArmor recognizes your organization automatically from your Google Workspace email domain — no manual configuration is needed. If your organization's domain isn't yet set up in DevArmor, the add-on shows a welcome card instead of the review workflow, with a link to sign up.
1. Open the add-on from the side panel in a Google Doc.
2. The first time DevArmor needs to read this document, grant it access — access is limited to the current file only.
3. Pick an existing DevArmor project, or create a new one directly from the doc.
4. Click **Run Security Review**. DevArmor reviews the document's contents against your organization's threat model.
5. While the review runs, the sidebar shows an estimated completion time; check status or open progress in the DevArmor web app at any point.
6. Once complete, the sidebar lists the resulting [security requirements](/modules/design-reviewer/review-output-and-findings) — click one to open it in DevArmor, or delete ones that don't apply.
You can re-run the review at any time (for example, after editing the document) with **Re-Run Security Review**, or switch to a different project with **Change project**.
### Prerequisites
* A DevArmor organization whose sign-up matches your Google Workspace email domain
* A Google Workspace account — personal Gmail accounts aren't supported, since the add-on recognizes you by your organization's domain
### Installation
1. Install **DevArmor** from the Google Workspace Marketplace, either as a Workspace admin (for the whole domain) or as an individual user.
2. Open a Google Doc and open the DevArmor add-on from the side panel.
3. If your organization isn't recognized yet, follow the sign-up link on the welcome card.
# Jira Integration (Security Design Review)
Connect DevArmor to your Jira workspace to automatically run security design reviews on new tickets and surface security requirements directly where engineers work.
### Overview
The Jira integration embeds DevArmor's Security Review workflow into your issue tracking process. When a developer creates a new Jira task or epic, DevArmor evaluates it against your organization's threat model and posts a structured security design review back into the ticket, before implementation begins.
Security requirements, recommended controls, and relevant design patterns reach engineers at planning time, not after the fact. Security engineers no longer need to manually triage every ticket: DevArmor classifies and reviews automatically, surfacing only the issues that warrant human attention.
Engineers interact entirely within Jira. The DevArmor Forge app adds a panel directly to each issue, showing the security review status and results inline.
### Integration Type
DevArmor connects to Jira using an **Atlassian Forge app** — Atlassian's native, cloud-hosted integration framework. The app is installed from the Atlassian Marketplace and runs on Atlassian infrastructure with permissions granted through the standard Atlassian app consent flow. No self-hosted components or custom webhooks are required.
**Supported platforms:** Jira Cloud only. Jira Server and Data Center are not supported yet.
**Permissions requested at install:**
* Read access to issues and projects
* Write access to post comments on issues
* Read access to user email addresses (for account matching)
### How It Works
#### Automated Security Review
```mermaid
flowchart LR
A[Developer creates\nJira task or epic] --> B[DevArmor classifies ticket]
B --> C{Security\nsignificant?}
C -- Yes --> D[Run security\ndesign review]
C -- No --> E[No action]
D --> F[Post requirements,\ncontrols & patterns\nto ticket]
```
DevArmor evaluates every new ticket against your threat model and posts review results back into Jira for security-significant work.
1. A developer creates a new task or epic in a monitored Jira project.
2. DevArmor classifies the ticket against your organization's threat model.
3. If security-significant, DevArmor runs a security design review and posts a structured comment to the ticket containing:
* Security requirements the implementation must satisfy
* Recommended controls for the specific feature
* Applicable design patterns from your organization's approved pattern library
4. If not security-significant, no action is taken.
#### Manual Review
From the DevArmor panel within any Jira issue, click **Run Security Review** to trigger or re-run a review on demand. Use this when a ticket has been updated since the initial automated review, or when the automated review was skipped.
#### Inline Panel
The DevArmor Forge app adds a panel to every Jira issue, visible in the backlog, board modal, and full-screen issue views, showing the review status and results without leaving Jira.
### Prerequisites
* A DevArmor organization with at least one threat model configured
* The DevArmor Forge app installed in your Atlassian workspace via the Atlassian Marketplace
* Jira Cloud workspace (Server and Data Center are not supported)
### Installation
1. Install the DevArmor Forge app from the Atlassian Marketplace. Follow the link from within DevArmor app's Integrations page, or use this [direct link](https://developer.atlassian.com/console/install/99e8156a-5a8d-4de0-872f-b3a41ff56c08?signature=AYABeETxK7eJgbL0hrcp0mvJa4YAAAADAAdhd3Mta21zAEthcm46YXdzOmttczp1cy13ZXN0LTI6NzA5NTg3ODM1MjQzOmtleS83MDVlZDY3MC1mNTdjLTQxYjUtOWY5Yi1lM2YyZGNjMTQ2ZTcAuAECAQB4IOp8r3eKNYw8z2v%2FEq3%2FfvrZguoGsXpNSaDveR%2FF%2Fo0BXCohExkzjSPPgCVMh8HihQAAAH4wfAYJKoZIhvcNAQcGoG8wbQIBADBoBgkqhkiG9w0BBwEwHgYJYIZIAWUDBAEuMBEEDO%2FIPQWIR2%2B85US6ZQIBEIA7ms9qr1AuOnDjx8Gzap%2Bk0W%2FNLmhUY4LNp5StGaWhBehhJM8gavG4qOEN5yrzPZVxOJUKtDRWcDN5hzsAB2F3cy1rbXMAS2Fybjphd3M6a21zOmV1LXdlc3QtMTo3MDk1ODc4MzUyNDM6a2V5LzQ2MzBjZTZiLTAwYzMtNGRlMi04NzdiLTYyN2UyMDYwZTVjYwC4AQICAHijmwVTMt6Oj3F%2B0%2B0cVrojrS8yZ9ktpdfDxqPMSIkvHAHrFvY6ClvsefAtxT3TBNSPAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMAHBw7KzxgkjJxPYgAgEQgDve8Fmp5ylYZP1hOw%2BctC%2FWexQWPkV2kMrLonShs1ChxFkI46t%2BYv5rIG%2F%2FYNbchvvZ8Hylb37%2FHUeIuQAHYXdzLWttcwBLYXJuOmF3czprbXM6dXMtZWFzdC0xOjcwOTU4NzgzNTI0MzprZXkvNmMxMjBiYTAtNGNkNS00OTg1LWI4MmUtNDBhMDQ5NTJjYzU3ALgBAgIAeLKa7Dfn9BgbXaQmJGrkKztjV4vrreTkqr7wGwhqIYs5AaPkP%2F15wcKa1vZhbNXytakAAAB%2BMHwGCSqGSIb3DQEHBqBvMG0CAQAwaAYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBLjARBAxfvwddkOH7ANVUhnECARCAOyFZyw37viPuJfWxorHvbPFOJHrx4iUs7ESsvAb%2BaMicAdsVGMZboWfcOsQjCNNNyM8sz1%2BxfURrAabtAgAAAAAMAAAQAAAAAAAAAAAAAAAAAFJ63O8zspM%2FvDIHqhmj%2B1H%2F%2F%2F%2F%2FAAAAAQAAAAAAAAAAAAAAAQAAADLzas6VXXfI9GFzoou%2FC3mh%2FEnii3r1O0%2BFePJCF1SurODGfI6oLzj%2FFlnev8t0sp%2BNtRdhEGp5uXROEDrmh6O0rfA%3D\&product=jira).
2. Accept the requested permissions during the Atlassian consent flow.
3. DevArmor matches your Atlassian workspace to your DevArmor organization using your email domain. No additional configuration is required.
All Jira projects are monitored by default. To restrict coverage to specific projects, update the **Monitored Projects** setting in your DevArmor organization settings.
### Review Output
| Field | Description |
| ----------------------------- | ----------------------------------------------------------------------------------- |
| **Potential Security Issues** | Potential issues, threats, and abuse cases identified based on the proposed design. |
| **Security Requirements** | Properties the implementation must satisfy, derived from your threat model. |
High-criticality items are security requirements; lower-criticality items are recommendations.
# Review Output & Findings
What a completed design review contains.
A completed design review surfaces two categories of findings:
| Field | Description |
| ----------------------------- | ----------------------------------------------------------------------------------- |
| **Potential Security Issues** | Potential issues, threats, and abuse cases identified based on the proposed design. |
| **Security Requirements** | Properties the implementation must satisfy, derived from your threat model. |
High-criticality items are security requirements; lower-criticality items are recommendations.
## Supporting detail
Depending on the design being reviewed, DevArmor also tracks:
* **Abuse cases** — specific ways the feature's use cases could be exploited, each tied to a use case and the access level required to carry it out.
* **Use cases** — the intended interactions between an actor and the feature.
* **Assets** — the things of value the design touches, that a threat actor might target.
* **Pen tests** — suggested penetration test scopes, each targeting a specific component, that can be pushed to a bug bounty program or pentest consultant.
* **Policies and rules** — the security policies applicable to the design, and, if configured, the [AI Guardrails](/modules/code-reviewer/ai-guardrails) rules that enforce them in code.
## Turning findings into work
Findings become tasks the same way threat model output does — see [Implement Threat Model Results](/modules/threat-modeler/implement-threat-model-results). Tasks created from a design review can be pushed to Jira or linked to an existing Jira issue, and stay in sync automatically when the linked issue's title, priority, status, or labels change.
# Code Reviewer
Automated security review of every pull request.
DevArmor's Code Review module automatically reviews every new pull request and suggests security improvements, correlating code changes with your design review results and flagging deviations from approved design patterns and security requirements.
To use Code Review, you don't need to change your workflow. DevArmor runs as a check in your GitHub check suite for every new PR and PR update, and posts results as a single consolidated comment showing each control's status, impact, and remediation together — with irrelevant checks hidden.
A review comment includes:
* A plain-English summary of the changes
* Clear explanations of each finding's impact
* Fix guidance that includes a code example
If DevArmor finds a potential improvement it can implement directly, it opens a separate pull request and links to it from the review comment — follow the link to review the proposed changes.
## Re-running a review
Comment **"@devarmor review"** on a pull request to re-run its security review at any time. DevArmor reacts with an emoji to acknowledge the request before starting.
## AI Guardrails
Beyond reviewing pull requests, Code Review's underlying policies can generate rule files for AI coding assistants like Cursor and Augment Code — see [AI Guardrails](/modules/code-reviewer/ai-guardrails).
# AI Guardrails
Turn security policies into rules your AI coding assistant follows.
AI Guardrails generates rule files for AI coding assistants — like Cursor and Augment Code — directly from your security policies, so the same requirements Code Review enforces on a pull request are available to an AI assistant while it's writing the code in the first place.
## Generating rules
You can generate a rule file:
* From an overall security policy, covering everything the policy applies to.
* From a specific design review, scoped to just that feature.
When setting up a rule, you can browse the repository's files and folders to scope it precisely.
## Scoping
Rules can be scoped to a specific **threat model**, **threat model version**, or **design review**, and filtered accordingly — so a rule only surfaces where it's actually relevant, instead of applying blanket guidance across every repository.
## From rule to pull request
You can open a pull request directly from a guardrail rule run, without leaving DevArmor, to apply the rule's suggested change.
# Secure Building Blocks
# Contact Support
{% embed url="" %}
# FAQ
Q: How do you handle hallucinations?\
A: *Use of RAG + agentic reasoning + internal benchmarking.*
Q: Will DevArmor replace my AppSec team?\
A: *No—DevArmor augments security engineers, automates tedium.*
Q: What if we use ChatGPT Enterprise already?\
A: *DevArmor provides consistent outputs, context-specific checks, and workflow integration. DevArmor's threat models are a database, not a blob of text. This dynamic database serves the basis for so many downstream tasks including:*
* *code review*
* *security requirements*
* *prioritization*
Q: What deployment models do you support?\
A: *We currently support Cloud deployment. However, we can support self-hosted, and hybrid options for our Enterprise customers.*
# Stay In Touch
How to stay connected and learn about the newest features
* [Blog](https://www.devarmor.com/blog)
* [LinkedIn](https://www.linkedin.com/company/devarmor/)
* [Newsletter](https://signal.devarmor.com/)
* [Book a meeting](https://calendly.com/amir-devarmor/30min)
# Security and Compliance
How we handle security at DevArmor
At DevArmor, security is foundational to everything we build. We follow secure-by-design principles and implement strict controls around data handling, model integrity, and access management. All customer data is encrypted in transit and at rest, and we support self-hosted and BYOM (Bring Your Own Model) deployment options to meet enterprise compliance needs. Our platform undergoes regular security assessments, and we leverage rigorous prompt evaluation, retrieval-augmented generation (RAG), and internal benchmarking to mitigate AI-related risks such as hallucination. DevArmor ensures that every security decision made by our AI agents is explainable, auditable, and aligned with your internal policies.
# Changelog
What's new in DevArmor, month by month.
This page tracks what's new in DevArmor — new capabilities, meaningful improvements, and notable fixes. It doesn't cover every internal change, just what affects your day-to-day experience.
## September 2026
**New**
* You can now connect DevArmor's AI assistant integration to the ChatGPT desktop app, in addition to other supported AI assistants. Combined with the guided threat-modeling workflow and full threat-model browsing added over the summer, you can now create a threat model, check its architecture and findings, and get a summary of remaining action items — all from your assistant of choice.
* AI Guardrails rules can now be scoped to a specific threat model, threat-model version, or design review, and filtered accordingly — and you can open a pull request directly from a guardrail rule run without leaving DevArmor. *Related: Security policies, Code Review.*
* You can import GitHub Wiki pages as a documentation source for threat models and design reviews, alongside Confluence, Google Docs, and Jira. *Related: Confluence integration, Google Drive integration.*
* You can scope a scan to a specific subfolder of a connected repository instead of always importing or reviewing the whole codebase.
* Jira tasks and epics can now be pulled in directly as a data source when setting up a threat model or design review, and "Push to Jira" now shows your organization's custom Jira fields and issue types that require them, so pushes no longer fail on missing custom fields.
**Improved**
* Jira and Confluence linking got faster: type-ahead search when linking issues, project search by name or key, and clearer errors on mismatched or missing permissions.
## August 2026
**New**
* Added support for signing in with OneLogin single sign-on (SSO), joining Okta, Microsoft, and Google. *Related: Okta SSO, Microsoft sign-in.*
* You can now attach memory sources — Confluence pages, Google Docs, Jira issues — to a project the moment you create it, and manage a project's connected memory sources directly from project settings, including turning memory use on or off per threat model or design review. *Related: Organizational Memory (July 2026), Confluence integration.*
* Confluence pages can now be added as a document source, and admins are alerted when a Confluence connection is missing required permissions so they can reapprove access in time.
* DevArmor now shows whether a project's memory will actually be used for a given build, with an explanation when it won't — so there are no surprises about what context went into a result.
* Diagram uploads now accept PDF files, and architecture generation from documents now takes diagrams and visuals in the file into account, not just the text.
**Improved**
* Security design reviews started from a Jira epic now automatically pull in its related sub-tasks and child issues, not just the top-level ticket.
* Tasks now show a clear status (to-do, in progress, done) and a priority aligned with Jira's scale, and stay in sync automatically when the linked Jira issue's title, priority, status, or labels change.
* Only organization admins can install or remove integrations, and any team member — not just admins — can now view the org's user list.
* Repositories linked to a project are now shared across threat-model versions instead of duplicated per version.
## July 2026
**New**
* Launched AI Guardrails — generate and manage AI coding-assistant rule files (for tools like Cursor and Augment Code) directly from your security policies, and browse a repository's files and folders when setting up a rule. *Related: Security policies, Code Review.*
* Launched DevArmor's AI assistant / MCP integration — create a threat model and check its architecture, findings, and progress directly from your AI assistant, with a guided end-to-end workflow that summarizes remaining action items.
* Introduced Organizational Memory — DevArmor now retains and reuses your organization's accumulated context (shared notes, business context) across projects and threat models, with a browsable version history. *Related: memory controls added in August.*
* Added an API Tokens section in Settings so you can generate and manage tokens for programmatic access to DevArmor. *Related: MCP / AI assistant integration.*
* Added a Version Diff view to compare two versions of a threat model side-by-side, showing exactly which threats, controls, and risks changed.
* You can now re-run a pull request's security review at any time by commenting "@devarmor review" on it, and DevArmor reacts with an emoji to acknowledge a review request before starting.
**Improved**
* Pull request review comments got a significant readability upgrade: a plain-English summary of the changes, clearer impact explanations, fix guidance that includes a code example, and each control's status/impact/remediation shown together (with irrelevant checks hidden).
* Architecture generation from code can now cover multiple linked repositories at once, modeling how they connect as a single system.
* Threats and attack patterns now show related MITRE ATT\&CK techniques and tactics for deeper context. *Related: STRIDE categorization, Attack Surface Analysis report.*
* Suggested penetration tests now specify exactly which system component they target.
* Pull requests now show a DevArmor status check directly in GitHub reflecting the review result, and results post as a single consolidated comment.
## June 2026
**New**
* Organizations can now upload, replace, and remove their own logo in DevArmor.
* Security controls can now be mapped to multiple relevant compliance requirements, and you can browse the complete list of supported compliance controls and frameworks when mapping — not just ones already in use. *Related: Attack Surface Analysis report.*
* You can generate architecture diagrams at the project level, not just within a single threat model, and choose to reuse the architecture from a version's base when creating a new version.
**Improved**
* The threat-model analysis report was redesigned with a reorganized structure, new charts, updated styling, and a system architecture diagram included directly in the report.
* DevArmor now requests read-only, reduced-scope access to Google Drive when you connect your account, instead of full read-write access — fewer permissions requested for the same functionality.
* GitHub integration setup no longer requires manually typing your organization name; it's detected automatically during installation. Removing the GitHub integration now also cleanly uninstalls the DevArmor app from your GitHub organization.
* Code review now only applies security controls from officially active policies, ignoring drafts.
**Improved / Trust & Safety**
* Uploaded files that could run as active web content (like HTML or SVG) are no longer accepted, to keep uploads safe.
* Documents imported from Google Docs now keep a link back to the original source document.
## May 2026
**New**
* Design reviews can now automatically interpret uploaded architecture and data-flow diagrams, and take previously uploaded diagrams into account when generating recommendations. *Related: diagram-to-architecture conversion (March 2026).*
* Design reviews can now be created and viewed directly from within the Google Docs add-on, matching the existing threat-model workflow. *Related: Google Drive integration.*
* Threat-model reports can now be generated and downloaded as a PDF, and exported directly from a project without needing to reference a specific version.
* Diagrams uploaded to a project now automatically generate the architecture's trust boundaries.
**Improved**
* Recommended tasks and controls now clearly identify the single security control that justifies them, and show which related components and threats they connect to — instead of a long, unfocused list.
* Deactivated users are now consistently blocked from taking any action in the product, closing a gap in access control.
* Improved the layout and readability of the Attack Surface Analysis report, including clearer category names.
* Creating a new threat-model version now automatically carries over its description from the version it's based on.
## April 2026
**New**
* Launched Attack Surface Analysis — a report that translates identified threats into a prioritized, ready-to-work set of engineering tasks. *Related: MITRE ATT\&CK mapping, compliance control mapping.*
* Reports can now be exported directly to Google Docs, with control over which Google Drive folder they're saved to.
* You can now create a security policy that spans multiple threat-model versions, and delete an entire threat model (not just a single version of it).
**Improved**
* Connecting a Google account now happens through a pop-up window instead of a full-page redirect.
* Trying to delete a resource that other items depend on now tells you exactly what those dependent items are, across the product.
* Architecture information gathered from code, uploaded diagrams, and documents is now combined automatically into one coherent, consistent view everywhere it's shown.
* A threat model's information now includes a list of all its versions, and you can manage which code repositories are linked to a specific version.
* Diagrams generated from architecture images are now more accurate and complete.
## March 2026
**New**
* You can now upload an image of an architecture diagram — including a photo or scan — and have it automatically converted into an editable digital diagram, processed in the background. *Related: automatic trust-boundary generation (May 2026).*
* Every identified threat is now categorized using the industry-standard STRIDE framework. *Related: MITRE ATT\&CK mapping (July 2026).*
* Projects can now contain multiple threat models, instead of just one, and creating the first version of a threat model no longer requires specifying a base version to copy from.
* Rule files for AI coding assistants can now be generated for a specific design review, in addition to an overall policy. *Related: AI Guardrails.*
* Added user roles, including a safeguard that prevents the last remaining admin from removing their own admin access.
* Added a Report gallery for browsing generated report artifacts, and a dedicated Settings page with tabs including Reports.
**Improved**
* You can now create and manage custom rules that guide DevArmor's automated design reviews.
* Risk scores and severity levels for findings are now calculated consistently using a defined formula.
* The Members page now shows your organization's real user data.
* Added a Mermaid diagram editor for directly editing a diagram's underlying code, with zoom, pan, and click-to-navigate between a diagram and its related table rows.
## February 2026
**New**
* Threat-model reports now include an AI-generated executive summary, summary statistics (documents and diagrams reviewed, threats/controls/risks identified), and can include a generated Privacy Impact Assessment.
* Diagrams now display trust-zone information for their elements, with clickable references to related items — and threat findings now indicate which architecture components each threat affects.
* Added a dedicated Policies page, with each policy showing its current status.
* Policies can now be given a status and snoozed until a future date.
**Improved**
* GitHub integration error handling throughout the connection flow now shows clear, specific messages (invalid organization, insufficient permissions, reconnection issues) instead of generic failures.
* The Report page now has a collapsible summary with a copy-to-clipboard button, and lets you show or hide individual sections. Report tables let you show, hide, reorder, and resize columns and rows.
* Redesigned the Threat detail view.
## January 2026
**New**
* Added dashboard tiles and charts summarizing your organization's threat models and design reviews.
* Introduced the foundation for AI Guardrails: generate rule files for AI coding assistants like Cursor and Augment Code directly from a security policy. *Related: AI Guardrails (launched July 2026).*
* Added a built-in Customer Support portal, plus "Contact Support" and "Share Feedback" links in the navigation.
* Added support for signing in with your Microsoft account, alongside existing sign-in options. *Related: Okta SSO, OneLogin SSO (2026).*
* Threat-model architecture can now be automatically generated by analyzing uploaded documents, and works even for repositories without a GitHub integration installed, by falling back to public access.
**Improved**
* Design reviews can now be linked to their associated documents and code repositories, and pushing a task to Jira now includes a link back to view it directly in Jira.
* Jira and Atlassian integrations now show a "stale" status if they stop receiving updates for more than 15 minutes.
* Increased the size of code and documents that can be analyzed without hitting input limits.
* Added pagination, filtering, and sorting to tables throughout the app, and made the Data Sources table fully drag-and-drop enabled.
