> For the complete documentation index, see [llms.txt](https://support.attackforge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.attackforge.com/app/getting-started/creating-and-managing-projects.md).
# Creating & Updating Projects
## Overview
A project is where a single piece of security testing lives, from setup through to the final report. Everything in AttackForge is organised around projects. Each project holds its **scope** (the assets being tested) and its **findings** (the vulnerabilities discovered), and every vulnerability is linked to the assets it affects.
## Why projects matter
Keeping each engagement in its own project gives you:
* **A clear boundary.** Scope, team, methodology, timeline and findings stay together, so nobody works from out-of-date spreadsheets or email threads.
* **Controlled access.** Only the people and groups you add can see the project, at the access level you choose.
* **Consistent delivery.** Test suites, scoring systems, vulnerability codes and email templates are set per project, so every engagement of the same type is run and reported the same way.
* **Data that flows on.** Findings feed into workflow automations ([Flows](/app/modules/flows.md)), group dashboards, analytics, [portfolios](/app/modules/portfolios.md), SLAs and reports automatically.
## What a project can be
A project can be any kind of security testing activity, including but not limited to:
| Application and code | Infrastructure | Adversary and compliance | People and places |
| ----------------------------------- | ------------------------------------------- | ----------------------------------- | ----------------------- |
| Web application penetration test | Network and infrastructure penetration test | Red team and purple team assessment | OSINT assessment |
| Web services / API penetration test | Wireless network assessment | PCI DSS assessment | Physical security audit |
| Mobile application penetration test | Configuration audit | SCADA assessment | |
| Source code review | Cloud Penetration Testing | Bug Bounties and VDP | |
## Who benefits
| Who | How projects help |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Security consultancies and MSSPs** | Each client engagement is run as a repeatable project, with the client given controlled access to their own results. |
| **Internal security teams** | Testing across applications and business units is tracked in one place, with findings routed to the right teams and SLAs. |
| **Testers** | A structured workspace, with the scope, test cases and reporting all in one place. |
| **Clients, developers and asset owners** | They see what was tested, what was found and what needs fixing, without waiting for a PDF. |
## Who can create projects
Only **Administrators**, **Project Coordinators** and **users with delegated privileges** can create projects. Other users can ask for one through a [project request](https://support.attackforge.com/app/getting-started/requesting-a-project).
## How a project fits together
A project can start from an approved request, from scratch, or as a clone of an earlier project. Once created, its findings feed workflow automations ([Flows](/app/modules/flows.md)), dashboards, [portfolios](/app/modules/portfolios.md), SLAs, notifications and reports without any extra work.
## Create a project
To start, open the **Projects** module from the main menu and select `New` → `Project` from the page menu. The Projects page also lists every project you can access.
{% hint style="info" %}
**Approving a project request?** When you select *Approve and Setup Project* on a request, you go through the same form, with the request details already filled in. See [Requesting a Project](https://support.attackforge.com/app/getting-started/requesting-a-project).
{% endhint %}
### Project name
The project name is how everyone, including testers, clients and stakeholders, identifies this piece of work in lists, dashboards, notifications and reports. Use a name people will recognise, such as *Acme Customer Portal: Web App Pentest, Q4 2026*.
### Project code
The project code is a short reference, often a job number, purchase order or internal ticket, that ties the project to systems outside AttackForge. It doesn't have to be unique and can be any value.
**Validating the code.** As you type, AttackForge checks whether another project already uses the same code. It can also fetch the latest project code, so you can keep a numbering sequence such as *PT-2026-041*, then *PT-2026-042*.
### Link groups
Linking a group is the quickest way to give a whole set of people the right access to a project, without inviting each person individually. You can link one or more groups, which might represent, for example:
* a customer
* a customer's third party, such as a development agency
* a customer's business units or subsidiaries
* a platform or technology
* a functional team
* a security team
When a group is linked:
* its members automatically get access to the project, at the access level set in the group's settings
* members can filter Analytics by the group
* the project's data appears in the Group Dashboard
{% hint style="info" %}
**Important:** group members don't receive project emails by default. To turn this on, change the group's settings when you create or update the group.
{% endhint %}
### Link portfolio streams
[Portfolios](/app/modules/portfolios.md) let leaders see risk across many projects, for example by business unit, product line or client. Linking a project to one or more portfolio streams means its vulnerabilities and assets appear in those portfolios automatically. Nobody has to add them by hand.
You can link portfolio streams when you create the project, when you approve a project request, or later when you edit the project.
### Scope
Scope defines what testers are authorised to test, and it is what every finding is linked to. An asset can be, for example:
| Testing type | Example asset |
| ---------------------- | ------------------------------------------------ |
| Web application or API | A URL |
| Application or server | An application or server name |
| Network | A subnet or IP address, such as `192.168.0.1/24` |
| Source code review | A file |
| Social engineering | A person |
| Physical audit | An address |
You can add assets in three ways:
* **Enter them manually.**
* **Paste a list.** For projects with a lot in scope, choose the delimiter that separates the assets in your list.
* **Select existing assets.** If you use the Assets module, you can choose from assets you already have access to. This keeps asset records, ownership and history consistent across projects.
[Assets Module](/app/modules/assets.md) *enabled:*
[Assets Module](/app/modules/assets.md) *disabled:*
### Test suites
A test suite is a methodology, playbook or checklist, made up of test cases. Applying one or more suites to a project means:
* **testers** structure their work the same way every time
* **clients** can see what was and wasn't tested
* **developers** can trace vulnerabilities back to the test cases that found them
Hover over a suite to see what it's for and how many test cases it contains. AttackForge comes with test suites based on industry benchmarks such as OWASP, MITRE, OSSTMM, among others. You can also build your own in the **Test Suites** module.
### Vulnerability scoring system
Scoring systems decide how severity is rated for findings in the project. Choose the ones that match what your client, regulator or internal policy expects.
You can apply **more than one scoring system to the same project**. AttackForge then shows the tester the score from each system for every finding, and the tester picks the priority that fits best. This helps when different audiences need different views. For example, a client's compliance team may need CVSS while their application owners think in OWASP risk terms, and the tester still makes the final call on priority.
{% hint style="info" %}
**Manual scoring is always available.** Testers can always set the priority manually, whichever other scoring systems are selected. Manual scoring can't be turned off.
{% endhint %}
| Option | How severity is rated | Use it when |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Manual** | Priority (Critical, High, Medium, Low, Info) plus Likelihood of Exploitation, from 1 (*Difficult to Exploit*) to 10 (*Trivial to Exploit*) | Always available to testers, and can't be turned off. Use it on its own for a simple rating, or when no formal methodology fits the assessment, such as physical or social engineering tests |
| **CVSS v3.1 Baseline** | CVSS v3.1 base score | You need a widely recognised industry-standard score |
| **CVSS v3.1 Baseline + Temporal** | Base score adjusted for exploit maturity and fix availability | Scores should reflect the current threat |
| **CVSS v3.1 Baseline + Temporal + Environmental** | All of the above, adjusted for the target environment | Scores should reflect the business impact in this environment |
| **CVSS v4** | The latest version of the CVSS standard | Your clients, regulators or internal policy require CVSS v4, or you want scores on the current version of the standard |
| **OWASP Risk Rating Methodology** | Overall risk from likelihood (threat agent and vulnerability factors) and impact (technical and business factors) | Application testing, where business impact matters as much as technical severity |
| **Microsoft DREAD** | Damage, Reproducibility, Exploitability, Affected users and Discoverability, each rated and combined into a score | Threat modelling, or teams that already rate risk with DREAD |
| **Custom scoring system** | Your own factors, scales and calculation, designed and built in the Administration module | Your organisation or clients have their own risk methodology that findings must follow |
### Vulnerability code
The vulnerability code gives every finding in the project a short, readable ID. People can then refer to *SEC01-4* in emails, tickets and meetings, instead of a long title. For example, with the code `SEC01`, the first vulnerability is `SEC01-1` and the second is `SEC01-2`.
You can change the code at any time, as long as it isn't used by any other project.
Changing the code updates the IDs of the project's existing vulnerabilities, except linked vulnerabilities. Those are managed in the settings of the project they came from.
{% hint style="info" %}
**Important:** changing the code can break references in external tools, such as ticketing systems, that use the old IDs.
{% endhint %}
### Apply SLAs on vulnerabilities
SLAs set a deadline for fixing each vulnerability based on its severity, so remediation is tracked against a clear target. This option only appears if SLAs are turned on in `Administration` → `Vulnerabilities` → `SLA`.
By default, SLAs are applied automatically to every new vulnerability, whether it is created or imported. Select **Manual** to opt out and apply SLAs yourself later. You might do this when you want to:
* start the clock only when the project ends
* start the clock only once the application team has acknowledged the findings
* apply SLAs only on certain projects, such as compliance or regulatory testing
* apply SLAs only to certain vulnerabilities
To apply them manually later, see re-apply SLAs on vulnerabilities in *Updating Vulnerabilities*.
### Custom fields
Custom fields let you capture the project information your organisation needs, beyond the standard settings. You configure them against projects in the **Administration** module in `Administration` → `Projects`, and they then appear on the project form for everyone creating or updating a project.
**Why use custom fields:**
* **Capture everything in one place.** Details that would otherwise sit in spreadsheets, emails or a separate ticketing system, such as commercial references, approvals and compliance drivers, stay with the project.
* **Make projects consistent.** Every project of the same type records the same information, which makes them easier to review, compare and audit.
* **Report and filter on what matters to you.** Custom field values can be used in filtering and searching, workflow automations, APIs, email templates, reports and more.
* **Fit your own process.** Mirror your consultancy's engagement workflow or your internal team's governance requirements without changing how AttackForge works.
**Examples:**
| Who uses it | Example custom fields |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Security consultancies and MSSPs | Purchase order number, statement of work reference, billing contact, account manager, engagement type (new or renewal) |
| Internal security teams | Business unit, application owner, data classification, release date, change request number, risk register reference |
| Compliance-driven testing | Compliance framework (such as PCI DSS or ISO 27001), audit period, auditor contact |
| Testing logistics | Testing window, out-of-scope systems, credentials handover method, emergency contact |
**Show or hide fields with logic.** Custom fields can be set to appear only when they're relevant, based on the values of other fields. For example, a *Compliance framework* field might appear only when *Compliance-driven test* is set to *Yes*, or *Change request number* only when the target is in production. Forms stay short, and people only see the questions that apply to them.
**Control who can view and edit each field.** Every custom field supports field-level access control for **View** and **Edit**. You decide who can see a field and who can change it. For example:
* commercial fields, such as purchase order or pricing, are visible only to Project Coordinators and Administrators
* a client can view the agreed testing window but not edit it
* only the security team can edit a data classification field
This means you can hold internal and sensitive information on the same project that clients and other stakeholders use, without exposing it to them.
### Email the project team on events
Email notifications keep people up to date without them having to log in. For example, a client's security lead can hear about a new critical vulnerability straight away, rather than waiting for the final report. Turn on the events that matter for this project, and team members then opt in to the notifications they want.
**How new vulnerabilities are notified.** Choose one of two options:
| Option | What's sent | Best for |
| ----------------------------------------------------------- | --------------------------------------------- | --------------------------------------------------- |
| **Send Individual Email For Each New Vulnerability** | One email per new vulnerability | High-severity alerts that need action straight away |
| **Send One Email with Details For All New Vulnerabilities** | One email summarising all new vulnerabilities | Busy recipients, or projects with many findings |
Both go to team members who have opted in and to any additional recipients you add.
**Email templates.** Each notification uses an HTML template, and a standard template is pre-loaded for you to adjust. You can use tags such as `{projectName}` or `{priority}` to insert project and vulnerability details. You can customise:
* the template for individual vulnerability emails
* the template for the summary vulnerability email
* the template for the daily start and stop testing email. This is sent to the project team, and you can add recipients outside the team, such as a SOC that needs to know when testing traffic is expected.
The full list of tags is in [Reference: email template tags](#reference-email-template-tags).
### Invite project team members
You can invite the whole team while you create the project, so everyone has access from day one. For each person, set:
| Setting | What it controls |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Access level** | What they can do in the project: View, Upload or Edit. See the info panel and the [Access Control Matrix](/app/access-control-matrix.md) for details. |
| **Project role** | Their role in the work, such as pentester, customer or developer. This is for collaboration only, so others know who does what. It doesn't grant privileges; access level does that. |
| **Notification events** | Which project emails they receive |
| **Test suites** | Assigns them to every test case in the selected suites, which spreads the testing workload across the team. Available to Edit users only. |
### Features
Feature settings let you decide what each audience sees. For example, you might hide reporting from a client until the report is final, or keep attack chains internal to the testing team. For each feature, set the minimum project access level needed to see it and which user roles get access.
| Feature | Can be turned off? | Notes |
| ----------------- | ------------------ | ------------------------------------------------------------------- |
| **Test Cases** | No, not currently | Set the minimum access level and the roles that can see them |
| **Retesting** | Yes | Controls retesting rounds |
| **Attack Chains** | Yes | Controls [Attack Chains](/app/getting-started/attack-chains.md) |
| **Reporting** | Yes |
Covers downloadable reports
and the Reporting section
|
### **Pages**
Pages give a project extra places to collaborate and share information, beyond findings and reports. Each page is its own space on the project, where the team can write content and upload files. You might use pages for:
* a **summary** of the engagement for stakeholders
* **rules of engagement**, contacts and escalation paths
* **testing notes** or a daily status log
* **handover material** for the remediation team, such as walkthrough videos or supporting documents
Pages give everyone on the project one place to find this information, so it doesn't end up scattered across email threads and shared drives.
**Turn pages on or off.** Each page has its own toggle, so you only show the pages a project needs.
**Control who can use each page.** Every page has its own access controls, so you can share some information widely and keep other pages to a smaller group. Use **Restrict Access To Following** and **Add Access** to choose who can use the page. Access is granted at three levels:
| Permission | Who has it by default |
| ------------------------ | ---------------------------------- |
| **View Page** | Project Access: View, Upload, Edit |
| **Upload Files to Page** | Project Access: Upload, Edit |
| **Edit Page** | Project Access: Edit |
The **Page Access Overview** lists who can view the page, upload files to it and edit it, so you can check access at a glance before you share anything sensitive.
{% hint style="info" %}
**Important:** Project Coordinators and Administrators always have access to every feature and page. This can't be restricted.
{% endhint %}
### Review and create
Check the details, then create the project. You're taken straight to the new project's dashboard.
## Manage a project
Once a project is created, its **Project Dashboard** becomes the control centre for the engagement. From there you can change settings, pause work, start the next round of testing, and eventually retire the project.
| Task | Who can do it | Where |
| --------------------------------- | ----------------------------------------- | --------------------------------------------------- |
| Update settings | Users with permission to edit the project | Cog icon, top right of the Project Dashboard |
| Place on hold or take off hold | Users with permission to edit the project | Project Dashboard |
| Clone a project | Administrators and Project Coordinators | `Clone Project` in the Projects module actions menu |
| View project logs | Administrators and Project Coordinators | Project settings |
| Archive, restore or destroy | Administrators | Projects module actions menu |
| Custom [Actions](/app/actions.md) | As configured | Projects module actions menu |
## Update a project
Select the **cog** icon in the top right of the Project Dashboard to open the project's settings. You can change most of the settings you chose at creation, such as scope, team, test suites, email templates and features.
## Place a project on hold or off hold
Place a project **On-Hold** when something blocks progress, such as a test environment being down, credentials not yet supplied, or a change freeze. Everyone then knows the work is paused and why, and the delay is recorded. Take it **Off-Hold** when work can resume. You can do this at any time.
When you change the status:
* the project team is emailed the reason
* the project's status is updated
* the change is logged in the project's tracking history, which you can see with the `Tracking` button on the Project Dashboard
This gives you a record of every delay, which is useful when you report on timelines or explain changes to the schedule.
## Clone a project
Cloning starts a new project from an existing one, so you don't rebuild the same setup each time. Administrators and Project Coordinators can clone projects. Use it to:
* **set up the next round of testing,** such as an annual pentest of the same application
* **track vulnerabilities for particular assets across projects**
* **retest only the open vulnerabilities** from a previous project
**What the new project gets:**
| Carried over | Details |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Project settings | Name, codes, test suites, scope, email templates, portfolios, custom fields and project team. You can change any of these before you create the clone. |
| Project workspace | All notes and files previously uploaded or created |
| Project notes | All previous project notes, except private notes |
| Executive summary | Including any uploaded files |
| Vulnerabilities | Optional. You choose which ones to bring across. |
To clone a project, select `Clone Project` in the Projects module actions menu.
1. **Configure the new project.** Review the settings carried over and change them as needed. For example, update the name, dates and scope for this round.
2. **Select vulnerabilities.** Choose any vulnerabilities from the source project to bring into the new one.
3. **Select options.** Choose from the cloning options, then select `Review and Create Project`.
{% hint style="info" %}
**Important: vulnerabilities are shared, not copied.** Vulnerabilities you bring across are linked to both projects. They stay in the source project and aren't duplicated. A change made in either project, such as a status update after a retest, appears in both. The assets affected by each vulnerability are added to the new project's scope.
{% endhint %}
Because the vulnerability is shared, its full history stays intact across rounds of testing. You can see when it was first found, when it was retested and when it was closed, without merging duplicates.
## View project logs
Project logs record every event on the project. Use them to troubleshoot ("who changed the scope, and when?") or for audit and reporting. Administrators and Project Coordinators can open the logs from the project's settings page.
## Archive, restore or delete a project
Archiving takes a finished or abandoned project out of day-to-day view without losing its data. Only Administrators can archive, restore or destroy projects.
| Action | What happens | How |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| **Archive** | The project moves to the archive. Non-admin users can no longer see it, and its vulnerabilities are left out of dashboards, analytics and other sections. | Select `Archive Project` in the Projects module actions menu, then confirm |
| **Restore** | The project returns to normal view | Open `Archived Projects` on the Projects page, then select `Restore Project` in the actions menu |
| **Destroy** | The project and all its data are deleted permanently | Open `Archived Projects`, then select `Destroy Project Data` in the actions menu |
{% hint style="info" %}
**Warning:** a destroyed project and its data can't be recovered. Archive a project if you might need it again, or if you need to keep it for audit or retention purposes.
{% endhint %}
## Tips and best practices
* **Use groups for access wherever possible.** One group for each client or business unit saves you from inviting people one at a time on every project.
* **Pick from the Assets module rather than retyping assets.** Findings then build up a history against the same asset across projects.
* **Agree the scoring system before testing starts.** Changing it partway through makes findings harder to compare.
* **Set the vulnerability code early and leave it alone.** Changing it later can break ticket references in other tools.
* **Clone for recurring tests and retests.** You keep the setup and the vulnerability history, and avoid duplicate findings.
* **Use On-Hold with a clear reason.** It explains schedule changes for you and leaves an audit trail.
* **Archive rather than destroy** unless you're sure the data is no longer needed.
## FAQ
**I can't see `New` → `Project`.** Only Administrators, Project Coordinators and delegated users can create projects. Ask one of them, or submit a [project request](https://support.attackforge.com/app/getting-started/requesting-a-project).
**I'm in a linked group but don't get project emails.** Group members don't receive project emails by default. An administrator needs to turn this on in the group's settings.
**Can I hide test cases from a client?** Test Cases can't be turned off at the moment, but you can set the minimum access level and the roles that can see them.
**If I clone a project and close a vulnerability in the new one, does it close in the old one too?** Yes. Vulnerabilities brought across when cloning are shared between the two projects, so their status is the same in both.
**Can I bring back a destroyed project?** No. Destroying a project is permanent. Archived projects can be restored.
## Related pages
* [Requesting a Project](https://support.attackforge.com/app/getting-started/requesting-a-project)
* [Groups](/app/modules/groups.md)
* [Portfolios](/app/modules/portfolios.md)
* [Assets](/app/modules/assets.md)
* [Test Suites](/app/modules/test-suite-builder.md)
* [Access Control Matrix](/app/access-control-matrix.md)
* [SLAs](/app/getting-started/vulnerability-slas.md)
* [Updating Vulnerabilities](/app/getting-started/updating-vulnerabilities.md)
* [Custom Email Meta Tags](https://support.attackforge.com/app/getting-started/notifications#custom-email-meta-tags)
## Reference: email template tags
All project email templates are sent as HTML, so include HTML tags in your template. A standard template is pre-loaded for each email, and you can adjust it. To add your own custom tags, see [*Custom Email Meta Tags*](https://support.attackforge.com/app/getting-started/notifications#custom-email-meta-tags).
### Individual email for each new vulnerability
This template is available when **Send Individual Email For Each New Vulnerability** is selected.
| Tag | Inserts |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| `{firstName}` | The team member's first name. Left blank for additional recipients who aren't on the team. |
| `{consultant}` | The first and last name of the consultant sending the email |
| `{projectName}` | The project name |
| `{priority}` | Critical, High, Medium, Low or Info |
| `{title}` | The vulnerability title |
| `{asset}` | The affected asset |
| `{likelihood_of_exploitation}` | A number from 1 to 10 |
| `{is_zeroday}` | Yes or No |
| `{description}` | The description |
| `{attack_scenario}` | The attack scenario |
| `{remediation_recommendation}` | The remediation recommendation |
| `{proof_of_concept}` | Steps to reproduce, in full HTML |
| `{notes}` | Notes |
| `{tags}` | Tags, as an unordered list |
| `{link}` | A hyperlink to the vulnerability in AttackForge |
| `{link.url}` | The vulnerability's URL on its own |
| `{key.}` | A vulnerability custom field, by its key. For example, the key `custom_score` becomes `{key.custom_score}`. |
| `{vulnerability.}` | A tag referenced in [Custom Email Meta Tags](https://support.attackforge.com/app/getting-started/notifications#custom-email-meta-tags) |
### One email for all new vulnerabilities
This template is available when **Send One Email with Details For All New Vulnerabilities** is selected. You can use `{firstName}`, `{consultant}` and `{projectName}` anywhere in the template.
{% hint style="info" %}
**Important:** vulnerability tags must go inside a `{vulnerabilities}` … `{/vulnerabilities}` block, which repeats for each vulnerability. For example: `{vulnerabilities}
{priority} - {title}
{/vulnerabilities}`
{% endhint %}
The tags you can use inside the block are: `{priority}`, `{title}`, `{asset}`, `{likelihood_of_exploitation}`, `{is_zeroday}`, `{description}`, `{attack_scenario}`, `{remediation_recommendation}`, `{proof_of_concept}`, `{notes}`, `{tags}`, `{link}`, `{link.url}` and `{vulnerability.}`. Each inserts the same value as in the individual email.
### Daily start and stop testing email
You set this template when you create or update a project. It's sent daily to the project team, and you can add recipients outside the team, such as a SOC.
| Tag | Inserts |
| ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `{firstName}` | The team member's first name. Left blank for additional recipients. |
| `{consultant}` | The consultant's first and last name |
| `{started_or_stopped_testing}` | "Started Testing" or "Stopped Testing" |
| `{projectName}`, `{projectStartDate}`, `{projectEndDate}` | The project name and dates |
| `{key.}` | A project custom field, by its key. For example, the key `out_of_scope` becomes `{key.out_of_scope}`. |
| `{project.}` | A tag referenced in [Custom Email Meta Tags](https://support.attackforge.com/app/getting-started/notifications#custom-email-meta-tags) |
| `{scope}` | The scope, as an unordered list |
| `{link}`, `{link.url}` | A link to the project in AttackForge, or its URL on its own |
| `{startTesting}` … `{/startTesting}` | Content sent only when testing starts |
| `{stopTesting}` … `{/stopTesting}` | Content sent only when testing stops |
| `{totalVulns}`, `{totalCriticalVulns}`, `{totalHighVulns}`, `{totalMediumVulns}`, `{totalLowVulns}`, `{totalInfoVulns}` | Total vulnerabilities, overall and by priority |
| `{totalVulnsToday}`, `{totalCriticalVulnsToday}`, `{totalHighVulnsToday}`, `{totalMediumVulnsToday}`, `{totalLowVulnsToday}`, `{totalInfoVulnsToday}` | Vulnerabilities found today, overall and by priority |
| `{totalActionedTestCasesToday}`, `{totalFailedTestCasesToday}` | Test cases actioned and failed today |
| `{totalRemainingTestCases}`, `{totalRemainingTestCases%}` | Test cases remaining, as a number and a percentage |
| `{totalCompletedTestCases}`, `{totalCompletedTestCases%}` | Test cases completed, as a number and a percentage |
{% hint style="info" %}
**Important:** asset tags must go inside an `{assets}` … `{/assets}` block. For example: `{assets}
{name} - {details}
{/assets}`. The tags you can use inside the block are `{name}`, `{type}`, `{details}`, `{external_id}` and `{key.}`, an asset custom field such as `{key.asset_owner}`.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://support.attackforge.com/app/getting-started/creating-and-managing-projects.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
