apPosture ai Wiki

How-to guides

apPosture Wiki

Hands-on, click-by-click walkthroughs for every module - what to press, what to type, in what order. Start with the golden path to get from zero to your first results, then dip into any module guide below. For deeper technical reference (config, API, deployment) see the Docs.

label = a button or option you click · field = something you type

The golden path - zero to first results

Almost everyone starts the same way. Follow these five steps in order and you'll have a real, prioritised list of vulnerabilities. Each step links to its full guide.

1 · Create an application

An application represents one product or service you're protecting. All its targets, scans and findings roll up here, and its risk grade is what leadership sees. Create it first.

  1. Open Assets → Applications in the sidebar (route /applications).
  2. Click + Add Application (top-right). The Add application dialog opens.
  3. Fill in Name (required, e.g. Customer Portal) and an optional Description.
  4. Pick Environment - prod / staging / dev - and Business criticality - critical / high / medium / low. These two drive the risk scoring, so be honest.
  5. Optionally set Owner team (e.g. Platform Security) so findings route to the right people.
  6. Click Add application. A card appears in the grid showing its risk grade (A–F), open vulns, exploitable count and SLA breaches.
Tip: if you skip this, items land under the auto-created Default application - fine for a quick test, but real reporting needs proper applications.

2 · Add a target

A target is a specific URL to scan, attached to an application.

  1. Open Assets → Targets (route /targets) and click + Add Target.
  2. Enter Name (e.g. Production API) and Target URL (e.g. https://app.example.com) - both required.
  3. Choose the owning Application from the dropdown (defaults to Default). Add a Description if useful.
  4. Optional - Source code (Hybrid AST): pick a Connected repository (connected on the Integrations page) or type a path. Giving the scanner your source unlocks deeper, source-informed exploitation later.
  5. Optional - Business-logic notes: describe the app's workflow in plain English (e.g. "Users book tickets, then pay at /api/checkout; price is sent in the request"). The AI turns these into a targeted test plan.
  6. If the app needs a login, set up authentication now (next section), then click Add Target.

3 · Set up authentication

Most serious vulnerabilities are behind the login. Authentication is configured on the target (in the same Add/Edit Target dialog), so every scan engine - not just the crawler - tests as a logged-in user. Pick the method that matches your app. They're mutually exclusive, except Mutual TLS, which layers on top of any of them.

Option A - Form login (most web apps)

  1. Tick Authenticated scan (form login).
  2. Enter the Login URL, plus the Username and Password of a test account.
  3. Set Username field name and Password field name to match the HTML form (defaults username / password).
  4. Add a Logged-in indicator regex (e.g. Logout|My Account) so the scanner can tell it's still authenticated.
  5. For IDOR / horizontal-access tests: fill the optional Second test account (User B's username + password).
  6. For MFA or multi-page logins: tick Advanced: recorded login steps, then add each step (GET/POST + URL + fields, including a TOTP secret for one-time codes) with + Add step.

Option B - OAuth2 / SSO

  1. Tick OAuth2 / SSO login.
  2. Enter the Token URL and choose a Grant type - Resource owner password, Client credentials or Refresh token.
  3. Provide client_id and client_secret; for the password grant also add username / password.
  4. Optionally set scope (e.g. openid profile api) and a Logged-in indicator.

Option C - API / token auth (no login form)

  1. Open the API / token auth dropdown and pick Bearer token, Session cookie, or Custom header.
  2. For Custom header, type the Header name; then paste the Header value (e.g. the bearer token).
  3. Optionally add a Logged-in indicator.

Optional - Mutual TLS (client certificate)

  1. Tick Mutual TLS (client certificate) - this combines with any auth method above.
  2. Paste the Certificate (PEM) and, unless it's bundled, the Private Key (PEM).
Verify it worked: on the New Scan screen the target shows a green 🔒 Authenticated badge. If it says Unauthenticated, recheck the login URL, field names and the logged-in indicator.

4 · Run a DAST scan

  1. Go to Testing → DAST Scans (route /scans) and click + New Scan.
  2. Pick your Target from the dropdown. Confirm the badges underneath - 🔒 Authenticated, 💻 Hybrid AST (source), ✓ Business-logic notes - reflect what you configured.
  3. Choose a Scan profile:
    • · Quick - spider only, ~5 min. A fast map.
    • · Standard - spider + active scan, ~30 min. The everyday choice.
    • · Deep - full active scan, 1–2 hrs. For a thorough audit.
  4. Optional - add Scope exclusions (one rule per line, e.g. /logout) so the scanner skips destructive or noisy URLs.
  5. Optional advanced - tick Crawl SPA (AJAX spider) for JavaScript-heavy apps; enable Gray-box deep exploitation if the target has source attached (you must also confirm I am authorized to actively exploit this target); or type plain-English hints under AI pentest instructions.
  6. Review the sticky summary panel on the right, then click ▶ Start Scan. You're taken to the live scan page (/scans/{id}) with real-time progress.

5 · Read & triage results

When the scan finishes, every confirmed issue flows into the unified Vulnerabilities list - de-duplicated and risk-ranked. Work it top-down.

  1. Open Findings → Vulnerabilities (route /vulnerabilities).
  2. Use the quick filter Exploitable first - these are proven, not theoretical, so they're the fastest wins.
  3. Click any row to open its detail page: evidence, remediation and which apps it affects.
  4. Set a status as you work - triaged, confirmed, in_progress, resolved, false_positive, risk_accepted…
  5. Select several rows to use bulk actions: Set status or Create Jira.

Short on time? Jump straight to Priorities for the few that matter, with an AI executive summary.

Discover assets (attack surface)

Not sure what you even own? Discovery maps subdomains and live hosts from a seed domain.

  1. Open Assets → Discovery (route /discovery) and click + New Discovery.
  2. Enter the Seed domain (e.g. example.com) and optionally assign an Application group.
  3. Choose Techniques: Certificate Transparency, DNS + reverse DNS, Subdomain brute-force, Live probe + fingerprint.
  4. Optionally expand Scope to add include/exclude domains, IP prefixes or TLDs.
  5. Tick the authorization box I am authorized to perform attack-surface discovery against this domain, then click Start Discovery.
  6. Watch the run on the list; click it to see discovered hosts, then promote any to a target.
Heads-up: discovery is fail-closed - if the seed isn't covered by a verified domain ownership it warns you. Only scan domains you're authorised to test.

Connect a repository (for code scanning)

  1. Open Assets → Integrations (route /integrations).
  2. Under Source Control, pick your provider: click GitHub (OAuth - you'll be redirected and back), GitLab (paste a token), or Local folder (upload source from your PC). A "Connected as …" banner confirms it.
  3. In the repository picker, choose the repo, its default branch and source path; it's added to Connected repositories.
  4. Use 🔄 Pull latest any time to re-sync, or 🗑️ Delete to remove it.

A connected repo can now be attached to a target (for Hybrid AST) and scanned under Code Security.

Scan code - SAST, SCA, Secrets, IaC, Containers

  1. Open Testing → Code Security (route /code, lands on Repositories).
  2. Find your connected repository in the table; use 🔄 Sync to pull the latest commit.
  3. Run a scan, then review findings on each tab:
    • · SAST - vulnerabilities in your own source (file : line).
    • · SCA - known CVEs in your dependencies (component @ version).
    • · Secrets - hardcoded keys & credentials.
    • · IaC - Terraform / Kubernetes / Dockerfile misconfigurations.
    • · Containers - vulnerable OS packages in image layers.
  4. On any sub-page, filter by severity, set a status, or create tickets in bulk. Everything also merges into the unified Vulnerabilities list.

Test APIs

Open Testing → API Security (route /api-security). It has five tabs:

  • Overview - KPIs and your most at-risk OWASP API categories.
  • OWASP Top 10 - coverage status across the 10 API risk categories.
  • Endpoints - the discovered API inventory (method + path + host), auto-populated from your DAST scans.
  • Findings - API-specific issues, each linking to the full vuln record.
  • Spec Audit - paste or upload an OpenAPI/Swagger spec and click Audit spec for a security score, auth-coverage % and an issues list - before you ship.

Import findings from other tools

Already run ZAP, Burp, Semgrep, CodeQL, Gitleaks, Checkov, Acunetix…? Bring those results in and let apPosture de-dupe and enrich them.

  1. Open Findings → Import Findings (route /import).
  2. Drop or select a Report file (.json / .sarif / .xml).
  3. Leave Format on Auto-detect (or pick the exact tool), and set the Application scope.
  4. Click Import. A banner reports how many were parsed, de-duped into vulns, enriched with live KEV/EPSS, and (on re-import) mitigated. Use the View in Vulnerabilities → link to continue.

Assessments - your run history

Open Findings → Assessments (route /assessments) to see every scanner run and import that fed your posture. Filter by application with the scope dropdown, and click any row to expand its individual findings. It's the audit trail of "where did this number come from?".

Triage vulnerabilities

The /vulnerabilities page is your single, de-duplicated worklist across all scanners.

  1. Click a severity card (Critical/High/…) or a quick filter (Exploitable, SLA breached, New, AI findings) to narrow the list.
  2. Refine with the source and status dropdowns, Sort (Risk/Severity/Age) and Group (Application / Target / OWASP / Project), or the search box (title, CWE, location).
  3. Open a row for full evidence, remediation and control mappings; change its status as you progress.
  4. Tick multiple rows to Set status or Create Jira in bulk.

Statuses: new · triaged · confirmed · in_progress · resolved · verified · closed · false_positive · risk_accepted.

Prioritise - the few that matter

Open Overview → Priorities (route /priorities) when the full list feels overwhelming.

  1. Click Generate under AI executive summary for a plain-language headline and "top actions".
  2. Read the funnel - it shows how the full set narrows to the handful that are reachable, exploit-confirmed and high-impact.
  3. Work the fix-first cards in order; each shows why it matters (exploit-confirmed, reachable, KEV) and links to the vuln.

Attack map - chained risk

Open Intelligence → Attack Map (route /attack-map).

  1. Filter by application / severity, or tick internet-facing / danger paths to focus.
  2. Read the Ranked attack paths - each shows an entry point → vuln → gate → impact, with a risk score and a Fix → button.
  3. Check Choke points - the single fixes that break the most attack paths at once (best effort-to-impact ratio).
  4. Expand an Attack chain and click Explain (AI) for a narrative, MITRE/CAPEC mapping and a recommendation, or Replay attack.

Threat models

  1. Open Intelligence → Threat Models (route /threat-models) and select an application.
  2. Click + New to have the AI draft a STRIDE model from what it knows about the app (or Import an existing one).
  3. When status reaches ready, open it: review each threat, see which ASPM controls already cover it, override status in-place, and use Print for a PDF.

Threat intel

Open Intelligence → Threat Intel (route /threat-intel). The Dashboard tab shows advisory severity, your exposure and a priority spotlight; the Feed tab is a searchable advisory stream (filter to Relevant only or KEV only, with EPSS scores).

Note: threat intel needs outbound access, which is off by default. If you see a "disabled" banner, an admin enables it in Settings - see the Docs.

CI/CD pipelines

  1. Open CI/CD → Pipelines (route /cicd) and click Set up a pipeline (→ /cicd/setup).
  2. Copy the snippet for your platform (GitHub Actions, GitLab CI, Jenkins…) into your repo - it calls the apposture CLI with your app/scan flags.
  3. Push code. The first run appears under Recent pipeline runs with a gate result (✅ Pass / ⚠️ Warn / ❌ Fail), findings and scanners used. Click a run to expand its detail.

Gates - block risky releases

  1. Open CI/CD → Gates (route /gates). Toggle between Applications and Repositories views.
  2. Each row shows the current gate decision, open count and last run; filter by Failing / Warning / Passing / Never gated.
  3. Click Run gate (▶) on a row to evaluate now. A repo not linked to an app shows 🔗 not linked - connect it via a target first.

What a gate enforces comes from your policies.

Policies & risk acceptance

  1. Open Governance → Policies (route /policies).
  2. Create a policy: give it a name, choose an Environment scope, tick rule presets (e.g. Fail on open Critical, Fail on exploit-confirmed, Warn on SLA breach), then Create. Power users can edit the rule YAML directly.
  3. Toggle policies on/off as needed; gates evaluate the enabled ones.
  4. To consciously accept a specific risk, record it under Risk acceptances with an expiry date - it's then excluded from gates until it expires.

Compliance & maturity

Open Governance → Compliance & Maturity (route /compliance). Three tabs:

  1. Controls - pick a framework (PCI-DSS, ISO 27001, SOC 2, NIST 800-53, HIPAA, GDPR) to see coverage %. For each control, leave the status on Auto or override it (Implemented / Partial / Gap / Not applicable) and attach evidence via Attest.
  2. Maturity - a DSOMM-style score (0–3) per dimension, auto-assessed from your platform activity, with manual overrides.
  3. Benchmark - compare each application's coverage and open-risk against your org average.

Posture coverage

Open Reporting → ASPM Coverage (route /posture) to see one posture across DAST + SAST + SCA - how many apps each engine covers, and the corroborated findings where vulnerable code (SAST) lines up with a runtime hit (DAST). Toggle By application / By target, or tick multi-source only to find the strongest-evidence issues. It answers "where are we under-tested?".

Generate reports

  1. Open Reporting → Reports (route /reports). The top shows your security score, KPIs and trend charts.
  2. Pick a report from the gallery - Executive/Board, Technical/AppSec, Compliance & Audit, Scan, Vulnerability Detail, Remediation & SLA, or Trend/Posture.
  3. In the dialog set the Scope, Period, any Frameworks, the Format (PDF/HTML/Excel/CSV/JSON) and language; tick Apply tenant branding; click Generate.
  4. From Recent reports: 📥 Download, Verify integrity, or create a Share link with an expiry. Use the schedule panel for recurring delivery.

Users, roles, MFA & API tokens

(Admin role required.)

  1. Open Administration → Identity & Access (route /admin/iam) to add users and assign roles (viewer / analyst / admin).
  2. Go to Administration → Account Security (route /admin/security) to enforce MFA (TOTP), set the password policy/lockout, and manage apt_ API tokens (generate, rotate, revoke).

Notifications

Open Administration → Notification Center (route /admin/notifications) to connect Slack, Telegram or Email (SMTP) and choose triggers - new critical/high finding, SLA breach, scan completion, gate failure, policy violation. Personal preferences live under Overview → Notifications.

That's the whole platform, click by click.

Need the deeper technical reference - architecture, configuration, the API? Head to the Docs.