# 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. # 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). 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 (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. ### 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. # Threat Modeler How to do threat modeling with DevArmor # Threat Modeler Overview An overview of DevArmor's Threat Modeler {% 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. A project can have multiple threat models. ## 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: * Import an existing threat model * Start from existing documents (release docs, PRDs, etc) * Describe the application and its attributes ## 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" %} ## Import existing documentation You can import existing documentation to provide more context for the threat model. This existing documentation includes: * Product Requirement Documents (PRDs) * Release documents * Vulnerability reports * CSPM outputs * SAST outputs To import documents, from the "Describe" section, select "Upload" and then upload documents. ## Describe and decompose the application # 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. # 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. # 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: These are tasks that need to be performed by security or engineering teams. You can directly push these tasks to your issue tracking platform. * Automated Tests: These are tests that DevArmor can automatically run in GitHub. They act as policies that apply to code review performed by DevArmor. * Maual Tests: These items are tests that cannot be run automatically and need to be run manually by users. * Penetration Tests: These are penetration test scopes that can be pushed to bug bounty programs or penetration testing consultants. # Design Reviewer DevArmor's Code Review module automatically reviews every new PR and suggest security improvements. To use the Code Review, you don't need to make any changes to your workflow. Simply pay attention to the DevArmor check that runs as part of the GitHub check suite for every new PR and PR updates. If DevArmor finds a potential improvement for a given PR, it generates a separate PR to implement it. In that case, DevArmor will include a link to the new PR in the comments section of its PR review. Simply follow the link to review the proposed changes. # 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. # Code Reviewer # 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.