Assess

Running Assessments

Start assessments manually, organize repeatable routines, use schedules, and connect CI/CD triggers.

Last updated August 2, 2026
On this page

Assessments execute Tahr testing workflows against a ready application. The types shown depend on the application setup and what is available for your organization.

#Choose the right assessment

Use the assessment type that matches your goal:

Type Purpose Principal prerequisite
Full Assessment Broad web application security testing. Ready application; authenticated setup when protected areas are in scope.
Full Assessment (No Authorization) Broad testing without authorization checks. Ready application.
AI/LLM Pentest Testing AI-specific attack vectors. Ready application with the AI feature in scope.
Vulnerability Retest Recheck selected previously reported vulnerabilities. A completed assessment with findings for the application.
Reconnaissance Discover and understand the external attack surface. Ready application and target scope.
Source Code Analysis Review a repository for code-backed security risks. Repository access.
Source Code Diff Review Review repository changes since a selected source analysis. Repository access and a completed source analysis with a captured commit.
Threat Modeling Identify threats, attack paths, assets, boundaries, and mitigations. Repository access; application documents when useful.
Android Pentest Test an Android application package. iOS application testing is not currently supported. APK support, uploaded APK, and application URL.

The exact Assessment type names above are the production labels. CI/CD is available for the assessment types that show a CI/CD option; Threat Modeling is started from the Tahr interface.

If a type is unavailable, check the readiness message and the prerequisite in this table. Assessment launches use credits when Tahr shows a credit requirement; the required amount can vary by type and plan.

New manual, CI/CD, and routine launches may be temporarily unavailable. Existing assessments can continue. Scheduled occurrences may be skipped or advanced while new launches are unavailable; check the schedule or run history before trying again.

#Manual runs

Manual runs are best for one-off assessments and validation after setup changes.

Before starting, review:

  • The Security Notices.
  • Target URLs and scope.
  • Authentication settings.
  • WAF or reserved IP requirements.
  • Any wait-for-deployment option shown by Tahr.
  • The selected assessment type.

Tahr shows credit use before a launch when applicable. Do not start a run until the selected type, scope, and credit requirement are correct.

#Choose an IP

When Tahr shows the IP selector, choose None (use dynamic IP) or an eligible reserved IP before launch. You must make this choice even when using a dynamic IP. Use a reserved IP only when you need a stable source IP for an allowlist or similar requirement. If an option is unavailable or occupied, wait or choose another eligible IP.

#Routines

Routines let you define a repeatable sequence of assessment steps. They are useful when your team wants the same process every time, such as recon before source-code analysis and runtime testing.

When a routine runs, later steps may reuse output from earlier steps when supported. This can reduce duplicate setup and improve context across the workflow.

For the full routine workflow, see Routines.

#Source Code Diff Review

Use Source Code Diff Review when you want to review changes made after an earlier Source Code Analysis, such as before a release or after a focused remediation change. The application must have repository access, and a completed Source Code Analysis must have captured a commit before a diff review can be started.

When you start the assessment, select the eligible completed Source Code Analysis shown by Tahr as the baseline. If no baseline is available, run or complete a Source Code Analysis first and confirm that repository access and the selected branch are ready. If Tahr shows a credit requirement or availability message for the selected review, confirm it before launching.

After the review completes, use Source Code to examine the source-backed results and Findings for any related finding workflow. See Source Code for result review and Source-code analysis is unavailable if repository access blocks the assessment.

#Schedules

Use Schedule for recurring assessments and release-cycle testing. Open Assessments, then Schedule. Schedule availability and reserved IP capacity can depend on your plan and permissions.

  1. Select the application and an available assessment type.
  2. For a target-based assessment, select an available reserved IP. Repository-only schedules do not use one.
  3. Choose the recurring frequency: hourly, daily, weekly, or monthly.
  4. Set the run time using your organization's timezone.
  5. Resolve any readiness message before saving. Confirm that test-account arrangements will still be available at each occurrence.
  6. When Tahr shows them for the selected assessment, configure run-level authentication, context, or other assessment settings.
  7. Create the schedule. When Run first now is shown, you can use it to validate the setup before waiting for the next occurrence.

Target-based schedules require a reserved IP. If the target uses a WAF, firewall, or IP allowlist, that IP may also need to be allowlisted. Threat Modeling, Source Code Analysis, and Source Code Diff Review schedules are repository-only and do not show the reserved IP field.

Open an existing Schedule to edit it, enable or disable it, or delete it when it is no longer needed. A scheduled occurrence can be skipped or blocked when the application is not ready, a required resource is unavailable, new launches are temporarily unavailable, or another active assessment conflicts with it. Check the schedule or run history, resolve the displayed issue, and see Assessment cannot start before retrying.

#CI/CD triggers

Use CI/CD to let a pipeline start an approved assessment without opening the Tahr UI. Open the application's CI/CD section, then generate a trigger token. Copy and store the token once in your CI/CD secret storage; do not place it in repository files, build logs, or shared configuration.

Configure the pipeline using only the endpoint, header, and body shown by Tahr. Select an assessment type supported by that application and visible in CI/CD. When Tahr shows a reserved IP option, select it only when the target's WAF, firewall, or allowlist requires it.

Use the application's CI/CD section to generate, regenerate, or disable a token. Regenerate the token if it is exposed or when personnel or CI/CD tooling changes, then update the stored secret before the next pipeline run. Application readiness, permissions, credits, and launch availability still apply to CI/CD-triggered assessments. If a trigger fails, confirm the current secret and selected type, then see CI/CD trigger does not work.

#During a run

Check the visible status and message first. Avoid starting duplicate active or queued launches. When offered, pause or resume the run; cancel it if the work must stop. Cancelling queued routine steps does not cancel an assessment that is currently active.

If the assessment finished but cleanup failed, use Retry cleanup when shown. Before retrying a failed or blocked launch, resolve the visible readiness, credits, authentication, launch availability, or WAF/IP blocker. See Troubleshooting for next steps.

Image preview