canonical: https://jentic.com/apis/hcltechsw.com/appscan

# Hcltechsw AppScan Rest API

HCL AppScan on Cloud is a security testing platform for static, dynamic, and software composition analysis. Its v4 REST API exposes the same operations as the AppScan UI plus additional automation hooks: managing application records, launching SAST and DAST scans, exporting issues, and integrating with asset groups and policies. Security teams use it to embed AppScan into CI/CD pipelines and pull issue data into ticketing systems for triage.

## For AI agents

Launch AppScan SAST, DAST, and SCA scans on registered applications, list issues, and manage asset groups and policies through the v4 REST API.

## Scope

Does not handle source-control hosting, runtime error monitoring, or container registry scanning - use for AppScan application security testing operations only.

## Capabilities

- Authenticate with an API key through /api/v4/Account/ApiKeyLogin to retrieve a bearer token for subsequent calls
- Register and configure target applications via /api/v4/Apps for SAST, DAST, or SCA scanning
- Group apps into asset groups for shared policy and reporting via /api/v4/AssetGroups
- Apply security and compliance policies to apps through the /api/v4/Apps/{appId}/Policy endpoints
- Track audit events and tenant-level activity via /api/v4/Audits
- Drive AppScan scans from CI pipelines and pull results into issue trackers

## Use cases

### CI Pipeline Application Security Scans

Wire AppScan into CI/CD so each merge to main triggers a SAST or DAST scan on the relevant application record. The pipeline calls /api/v4/Account/ApiKeyLogin to mint a token, posts to the apps endpoint to create or update the target, and then runs scans through the AppScan v4 endpoints. Findings flow back into the build log so developers see issues alongside test failures.

Example prompt: Authenticate with an API key, create or update an app via /api/v4/Apps, and verify the response returns an application id

### Policy and Compliance Management at Scale

Large security programs apply different policies - OWASP Top 10, PCI, internal hardening - to different application portfolios. Use /api/v4/Apps/{appId}/Policy to attach the right policy to each app and /api/v4/AssetGroups to group apps so policy assignment can be done at the group level. This keeps compliance reporting clean as the portfolio grows.

Example prompt: List existing policies, then POST to /api/v4/Apps/{appId}/Policy/{policyId} to attach the OWASP Top 10 policy to a target app

### Audit Trail Export to SIEM

Pull tenant audit events from /api/v4/Audits into your SIEM or data lake to track who did what - scans launched, policy changes, user invites - across the AppScan tenant. The /api/v4/Audits/AdditionalData/{auditId} endpoint returns the full payload for each event when an investigation needs detail. This gives security teams a queryable record without screen-scraping the UI.

Example prompt: GET /api/v4/Audits filtered by date, then call /api/v4/Audits/AdditionalData/{auditId} for any high-severity events and push the payload to the SIEM

### AI Agent Security Triage via Jentic

An agent searches Jentic for 'list application security findings' and Jentic returns the relevant AppScan apps and audit operations. The agent fetches issues, groups them by severity, and opens tickets in the issue tracker - all without storing the AppScan API key locally because Jentic securely stores it. This turns AppScan into a triage-ready tool for security copilots.

Example prompt: Use Jentic to call /api/v4/Account/ApiKeyLogin and then list apps via /api/v4/Apps with a filter for the team's portfolio

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /api/v4/Account/ApiKeyLogin | Exchange an API key for a bearer token |
| GET | /api/v4/Apps | List registered applications |
| POST | /api/v4/Apps | Register a new application |
| PUT | /api/v4/Apps/{id} | Update an application record |
| POST | /api/v4/Apps/{appId}/Policy/{policyId} | Attach a policy to an application |
| GET | /api/v4/AssetGroups | List asset groups |
| GET | /api/v4/Audits | Read tenant audit events |

## Key resources

- **Account** — Authenticate, manage tenant info, and invite users via /api/v4/Account
- **Apps** — Register and configure scan targets via /api/v4/Apps
- **AssetGroups** — Group apps for shared policy and reporting via /api/v4/AssetGroups
- **Audits** — Read tenant audit events via /api/v4/Audits
- **Policy** — Attach security and compliance policies through the per-app Policy endpoints

## Why Jentic

- **Setup:** Wiring AppScan by hand means either sending the X-API-KEY header or first exchanging your key for a bearer token via /api/v4/Account/ApiKeyLogin, then attaching it per operation. Through Jentic you install once, import the AppScan REST API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** AppScan puts the application id in the URL path (/api/v4/Apps/{id}, /api/v4/Apps/{appId}/Policy/{policyId}), so a rule can pin your agent to one application: it can read and list for that app and nothing else. You choose the operations it may call, so changes like attaching a policy or updating an app are not included unless you add them.
- **Credential handling:** Your AppScan API key is stored once, encrypted, by your own Jentic One instance and either attached as the X-API-KEY header or exchanged for a bearer token at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list applications' or 'attach a security policy', and Jentic returns the matching AppScan v4 operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Snyk API** — Snyk covers SCA, SAST, and IaC scanning with a developer-first workflow; AppScan focuses on enterprise SAST and DAST
- **GitHub API** — GitHub hosts the source code and CI workflows that trigger AppScan scans
- **Sentry API** — Sentry tracks runtime errors that often correlate with vulnerabilities AppScan flags statically

## FAQ

### What authentication does the AppScan Rest API use?

AppScan supports two schemes: an X-API-KEY header for direct calls, and a bearer token returned by POST /api/v4/Account/ApiKeyLogin for session-style use. Jentic stores the API key in the vault and either passes it directly or exchanges it for a token before calls.

### Can I launch a DAST scan from the AppScan Rest API?

Yes. Register the target through /api/v4/Apps, attach the DAST configuration, and trigger scans through the corresponding scan endpoints in the v4 surface. The same flow works for SAST and SCA targets.

### How do I attach a policy to an application?

Call POST /api/v4/Apps/{appId}/Policy/{policyId} with the application id and the policy id. To remove a policy, send DELETE to the same path. Use /api/v4/Apps/{appId}/Policy to list what is currently attached.

### What are the rate limits for the AppScan Rest API?

AppScan on Cloud applies tenant-level rate limits but does not publish a numeric limit in the spec. For high-volume CI integrations, batch reads where possible and back off on HTTP 429 responses.

### How do I list all my AppScan applications through Jentic?

Search Jentic for 'list application security findings' or 'list applications' and load the /api/v4/Apps GET operation for hcltechsw.com. Jentic injects the X-API-KEY header from the vault, so the call returns the list with no local credential handling.

### Can the AppScan API export audit events for a SIEM?

Yes. GET /api/v4/Audits returns tenant audit entries, and /api/v4/Audits/AdditionalData/{auditId} returns the full payload for a specific event. Page through results and forward each entry to your SIEM ingestion endpoint.

### Can I limit what my agent is allowed to do with the AppScan Rest API?

Yes. Because you run Jentic One yourself, your own rules decide which AppScan operations and credentials the agent may use. AppScan puts the application id in the URL path, such as /api/v4/Apps/{id} and /api/v4/Apps/{appId}/Policy/{policyId}, so you can pin the agent to a single application and let it only read and list for that app. Write actions like registering an app via POST /api/v4/Apps or attaching a policy stay out of reach unless you explicitly allow those operations.