# Vulnsy Docs — Full Corpus > Concatenated markdown of every page under docs.vulnsy.com/docs, in file-tree order. Regenerated from `content/docs/` on each request (ISR-cached for 1 hour). --- --- title: Email Templates description: Customize the email notifications Vulnsy sends to your users and clients — subject lines, body content, branding, and per-event template overrides. --- import { Callout } from 'fumadocs-ui/components/callout'; Vulnsy sends email notifications for events like portal document sharing, user invitations, and status changes. You can customize these emails to match your organization's tone and branding. ## How Email Templates Work Each notification type has an email template that defines: - **Subject line** -- the email subject - **Body content** -- the email body, which supports HTML formatting - **Template variables** -- dynamic placeholders replaced with actual data at send time ## Template Variables Use variables in your templates to insert dynamic content. Variables are wrapped in double curly braces: ``` Hello {{client_name}}, A new document has been shared with you for {{project_name}}. Log in to your portal to view it: {{portal_link}} Regards, {{organization_name}} ``` Available variables depend on the notification type — the template editor lists exactly which variables you can use for each specific email, so you never have to guess. ## Editing Templates 1. Go to **Admin > Email Templates** 2. Select the template you want to customize 3. Edit the subject line and body content 4. Preview the result 5. Save ## Custom vs Global Templates | Type | Description | |------|-------------| | **Global templates** | Default templates provided by Vulnsy. Available to all organizations. | | **Custom templates** | Templates you create or modify. Override global templates for your organization. | You can: - Modify a global template to create an organization-specific version - Create entirely new custom templates - Enable or disable specific global templates for your organization Disabling a global email template means that notification will not be sent unless you have a custom template in its place. --- --- title: Administration description: Manage users, permissions, templates, and organization settings in Vulnsy — admin tools for configuring your team, branding, and report defaults. --- import { Callout } from 'fumadocs-ui/components/callout'; Organization administrators control how Vulnsy is configured for their team. The admin section covers user management, role-based permissions, report templates, email templates, and organization-wide settings. ## Accessing Admin Features Admin features are available from the **Admin** section in the sidebar. Only users with the **Admin** role can access these pages. ## What You Can Manage | Area | Description | |------|-------------| | **Permissions** | Configure role-based access control for your organization | | **Report Templates** | Upload and manage DOCX templates for report exports | | **Organization Settings** | Configure branding, portal settings, module toggles, and storage | | **Email Templates** | Customize email notifications sent by Vulnsy | If you cannot see the Admin section in the sidebar, contact your organization administrator to check your role. ## Next Steps - [Permissions](/docs/admin/permissions) -- understand and configure role-based access - [Report Templates](/docs/admin/report-templates) -- manage DOCX export templates - [Organization Settings](/docs/admin/organization-settings) -- configure your organization - [Email Templates](/docs/admin/email-templates) -- customize notification emails --- --- title: Organization Settings description: Configure your organization's name, branding, portal settings, feature modules, storage, and defaults applied across every report and engagement. --- import { Callout } from 'fumadocs-ui/components/callout'; Organization settings let administrators configure how Vulnsy works for their team. Access these settings from **Admin > Organization Settings**. ## General Settings | Setting | Description | |---------|-------------| | **Organization name** | Your company or team name, displayed across the platform | | **Branding** | Logo and branding elements used in the portal and exports | ## Portal Settings Control whether the client portal is available for your organization: - **Enable/disable client portal** -- toggle portal access on or off - When disabled, clients with the Client role cannot access the portal ## Platform Modules Vulnsy includes optional modules that are enabled per workspace as part of your subscription plan: | Module | Description | |--------|-------------| | **Client Portal** | Share reports and documents with clients through a secure portal | | **QA** | Internal quality-assurance review workflows | | **Scoping** | Engagement scoping and cost-estimation tools | | **Disclosure** | Vulnerability disclosure management | When a module is disabled it is hidden from the sidebar and navigation; existing data is preserved and reappears if the module is re-enabled. Contact [support@vulnsy.com](mailto:support@vulnsy.com) to change which modules are available on your plan. ## Storage Monitor your organization's file storage usage: - View total storage used - See a breakdown by file type (templates, evidence, portal documents) - Check your plan's storage limit ## S3 Configuration Vulnsy uses AWS S3 for document and file storage. The S3 configuration status shows whether storage is correctly set up for your organization. If the S3 status shows an error, file uploads (evidence, templates, portal documents) will not work. Contact support at support@vulnsy.com if you see configuration issues. ## Email Configuration View and manage your organization's email sending configuration. This controls how notification emails are sent to your users and clients. --- --- title: Permissions description: Role-based access control in Vulnsy — understand the available roles, what each one can access, and how to assign permissions to your team members. --- import { Callout } from 'fumadocs-ui/components/callout'; Vulnsy uses role-based access control (RBAC) to manage what each user can see and do within your organization. Every user is assigned a role, and each role defines a set of permissions. ## Available Roles | Role | Description | |------|-------------| | **Admin** | Full access to all features. Can manage users, roles, templates, and organization settings. | | **Consultant** | Can create and edit clients, projects, findings, and reports. The primary role for pentesters doing day-to-day work. | | **Third Party** | External collaborators (partner firms, subcontracted testers). Access is limited to the specific projects and reports they are granted. | | **Viewer** | Read-only access. Cannot create or edit any data. | | **Client** | Portal access only. Can view and download documents shared through the client portal. Cannot access internal projects or findings. | ## Permissions Matrix | Action | Admin | Consultant | Third Party | Viewer | Client | |--------|:-----:|:----------:|:-----------:|:------:|:------:| | Manage users and roles | Yes | -- | -- | -- | -- | | Organization settings | Yes | -- | -- | -- | -- | | Manage templates | Yes | -- | -- | -- | -- | | Create/edit clients | Yes | Yes | -- | -- | -- | | Create/edit projects | Yes | Yes | -- | -- | -- | | Create/edit findings | Yes | Yes | Assigned projects | -- | -- | | Create/edit reports | Yes | Yes | Assigned projects | -- | -- | | View reports | Yes | Yes | Assigned only | Yes | -- | | Export reports | Yes | Yes | Assigned only | -- | -- | | Portal access | -- | -- | -- | -- | Yes | The permissions matrix is configurable per organization. The table above shows the default configuration. Admins can adjust permissions from **Admin > Permissions**. ## Managing Roles To assign or change a user's role: 1. Go to **Admin > Users** 2. Select the user 3. Choose the new role from the dropdown 4. Save changes ## Resetting Permissions If your permissions configuration has become complex or inconsistent, you can reset to defaults: 1. Go to **Admin > Permissions** 2. Click **Reset to Defaults** 3. Confirm the reset Resetting permissions overwrites all custom permission changes for your organization. This cannot be undone. --- --- title: Report Templates description: Upload and manage DOCX report templates that control the structure and formatting of your exported pentest reports. --- import { Callout } from 'fumadocs-ui/components/callout'; Report templates are DOCX files that define the structure and visual formatting of your exported reports. When you export a report, Vulnsy merges your engagement data into the template to produce the final document. ## Template Types | Type | Description | |------|-------------| | **Organization templates** | Templates uploaded by your team. Only visible to your organization. | | **Global templates** | Templates provided by Vulnsy, available to all organizations. Can be toggled on or off. | ## Uploading a Template 1. Go to **Admin > Templates** (`/admin/templates`) 2. Click **Upload Template** 3. Select a `.docx` file from your computer 4. Give the template a name 5. Save The template is now available for selection when exporting reports. ## Setting a Default Template You can designate one template as the default for new reports: 1. Go to **Admin > Templates** 2. Find the template you want to set as default 3. Click **Set as Default** New reports will automatically use this template unless a different one is selected. ## Template Syntax Templates use [Docxtemplater](https://docxtemplater.com/) syntax for dynamic content. Tags in your template are replaced with data from Vulnsy during export. ``` {report.title} {client.name} {#findings} {title} - {severity} {/findings} {%image} ``` For the full list of available template tags and syntax reference, see the [Report Export](/docs/reports/export) documentation. ## Global Template Visibility By default, Vulnsy's global templates are visible to your organization. To hide them: 1. Go to **Admin > Templates** 2. Toggle off **Show Global Templates** This is useful if your organization has its own templates and you want to avoid confusion. ## Report Styles Report styles control the visual formatting applied to your exports -- fonts, colors, heading styles, and table formatting. Styles are configured alongside templates and applied during the export process. When editing templates in Word, type tags in one continuous motion. Do not copy/paste or edit tags after typing, as Word may split the tag across multiple XML runs and break the replacement. See [Export Issues](/docs/troubleshooting/export-issues) for more details. --- --- title: AI Assistant description: Vulnsy's AI writing assistant helps you draft findings, executive summaries, and rewrites directly inside the report editor. Use Vulnsy's managed AI, your own API key, or a self-hosted model. --- import { Cards, Card } from 'fumadocs-ui/components/card'; import { Callout } from 'fumadocs-ui/components/callout'; The AI writing assistant is built into the Vulnsy report editor. From any rich-text field you can ask it to draft a finding, write an executive summary, or improve, shorten, expand, or reformat what you have already written. It always works from the content you are editing, so the output fits the report in front of you. AI is optional and off until an admin enables it. Enabling it is free and open to every workspace. Only using Vulnsy's own managed AI needs a paid add-on, and that add-on is included free during your trial. ## Explore ## What It Does - **Draft findings** from rough notes, with description, impact, remediation, and a suggested CVSS. - **Write executive summaries** aimed at a non-technical business audience. - **Rewrite selected text**, for example make it more formal, shorten it, expand it, fix grammar, or translate it. - **Compose fresh content** from a plain-language instruction, grounded in the field you are editing. Every result is a draft you review before it goes into the report. Nothing is saved automatically. ## Ways to Run It Each workspace chooses one of three provider modes: | Mode | Whose AI | Cost | |------|----------|------| | **Managed (Vulnsy AI)** | Vulnsy's AI service | Paid add-on, free during the trial | | **Bring your own key** | Your own OpenRouter API key | Free, you pay OpenRouter directly | | **Bring your own endpoint** | A self-hosted, OpenAI-compatible model | Free, runs on your own infrastructure | See [Provider Modes](/docs/ai/provider-modes) for how each one works and how to configure it. ## Turning It On 1. Go to **Admin**, then **Organization Settings**. 2. Open the **AI** tab. 3. Choose a provider mode and save. Once enabled, the AI controls appear in the report editor for everyone in your workspace. Your privacy is the priority. Managed AI routes only through zero-data-retention providers, prompts and generated text are never stored, and client identifiers are redacted from requests by default. See [Privacy & Limits](/docs/ai/privacy-and-limits). --- --- title: Privacy & Limits description: How Vulnsy protects your data when you use AI, and the usage limits that keep the service fair and predictable. --- import { Callout } from 'fumadocs-ui/components/callout'; AI is built with client confidentiality as the priority. This page explains how your data is handled and what usage limits apply. ## How Your Data Is Handled - **Zero data retention.** Managed AI and bring-your-own-key mode route only through providers that are configured to not retain or train on your data. - **Nothing is stored.** Your prompts and the generated text are never saved by Vulnsy. Only lightweight metadata, such as token counts, is recorded so usage can be metered. - **Client identifiers are redacted.** Before a request is sent, identifying details such as the client name, domains, and hosts are replaced with placeholders, then restored in the response you see. This is on by default. - **Secrets are encrypted.** Your own API key or endpoint token is stored encrypted and is never shown again after saving. - **Requests run server-side.** AI calls are made from Vulnsy's servers, never from your browser. Provider keys are never exposed to the client. In short: managed AI never trains on or keeps your data, prompts and outputs are not stored, and client identities are stripped from requests by default. ## Usage Limits Limits keep the service responsive and costs predictable. They apply to managed AI: - **Monthly allowance.** Each plan includes a pooled monthly allowance of generations, shared across your team. When it is used up, managed AI pauses until the allowance resets at the start of the next month. See [Provider Modes](/docs/ai/provider-modes) for the allowance per plan. - **Per-request size.** Each request has a sensible cap on how much it reads and writes, so a single action stays fast and reasonably sized. - **Rate limit.** There is a short-term limit on how many requests a single user can make in quick succession, which prevents accidental runaway usage. Bring-your-own-key and bring-your-own-endpoint modes have no Vulnsy allowance. Usage is governed by your own provider account or your own infrastructure. ## Checking Your Usage Your workspace's remaining monthly allowance is shown in the usage indicator next to your profile, in the bottom-left of the app. Admins can review and adjust AI settings for the workspace from **Admin**, then **Organization Settings**, then the **AI** tab. ## Next Steps - [Provider Modes](/docs/ai/provider-modes) for allowances and configuration. - [Writing Assistant](/docs/ai/writing-assistant) to start drafting with AI. --- --- title: Provider Modes description: Choose how AI runs for your workspace, from Vulnsy's managed AI to your own OpenRouter API key or a self-hosted model endpoint, and see managed pricing and allowances. --- import { Callout } from 'fumadocs-ui/components/callout'; Every workspace runs AI in one of three modes. Enabling AI is free and open to everyone. Only Vulnsy's managed AI is a paid add-on, and it is included free during your trial. Configure the mode under **Admin**, then **Organization Settings**, then the **AI** tab. ## Managed (Vulnsy AI) Vulnsy runs the AI for you, so there is nothing to set up beyond turning it on. Managed AI is a paid add-on, sized to your plan, with a monthly allowance of AI **generations** that is pooled and shared across your whole team. | Plan | Monthly allowance | Add-on price | |------|-------------------|--------------| | **Solo** | ~200 generations | £10 / month | | **Team** | ~1,000 generations | £39 / month | | **Business** | ~3,000 generations | £99 / month | A generation is one AI action, such as drafting a finding or rewriting a paragraph. The allowance is shared, so any member of your team draws from the same monthly pool. It resets at the start of each month. Managed AI is included free during your trial so you can evaluate it before subscribing. After the trial, add it from the subscribe or change-plan screen. ## Bring Your Own Key Connect your own [OpenRouter](https://openrouter.ai/keys) API key and use AI with no usage charge from Vulnsy. You pay OpenRouter directly for what you use, and there is no monthly allowance from us to run out of. To set it up: 1. Create a key at [openrouter.ai/keys](https://openrouter.ai/keys). 2. In the **AI** tab, choose **Bring your own key** and paste it in. 3. Optionally set a preferred model. Your key is stored encrypted and is never shown again after you save it. You can replace it at any time. ## Bring Your Own Endpoint Point Vulnsy at your own OpenAI-compatible model endpoint, for example a self-hosted model exposed over HTTPS. This keeps generation entirely on infrastructure you control, with no usage charge from Vulnsy. To set it up: 1. In the **AI** tab, choose **Bring your own endpoint**. 2. Enter the endpoint URL and, if required, an access token. 3. Optionally set the model name your endpoint expects. Custom endpoints are validated to block requests to private and internal network addresses. Your endpoint must be reachable over HTTPS. Any access token you provide is stored encrypted and sent as a bearer token. ## Which Mode Should I Choose? | If you want | Choose | |-------------|--------| | The simplest option with nothing to manage | Managed (Vulnsy AI) | | To use your own AI account and billing | Bring your own key | | To keep AI on your own infrastructure | Bring your own endpoint | ## Next Steps - [Writing Assistant](/docs/ai/writing-assistant) to start using AI in the editor. - [Privacy & Limits](/docs/ai/privacy-and-limits) for data handling and usage limits. --- --- title: Writing Assistant description: How to use the AI writing assistant inside the Vulnsy report editor, from the toolbar and the highlight menu, and how to apply the results. --- import { Callout } from 'fumadocs-ui/components/callout'; The assistant lives inside every rich-text field in the report editor. There are two ways to reach it, and each is suited to a different task. ## Ask AI From the Toolbar Click the **sparkle (Ask AI)** button in the editor toolbar to open the Ask AI window. Type what you want in plain language and the assistant uses the **whole field** as context. This is best when you want to write something new, or transform the entire field. For example: - "Write a remediation section for a stored XSS in the comments field" - "Make this sound more professional" - "Summarise these findings into an executive summary" When the draft is ready you can: - **Insert** it at your cursor, or - **Replace all** to swap the entire field for the new version. ## Ask AI From a Selection Highlight some text and an **Ask AI** button appears. Click it to open the window with your selected text shown for reference. Your instruction is applied to that selection. This is best for focused edits. For example: - "Make this more concise" - "Rewrite this in a more formal tone" - "Translate this to French" - "Fix the grammar" When the draft is ready you can: - **Replace selection** with the result, or - **Insert after** to keep the original and add the new text below it. The toolbar button uses the whole field for context. The selection menu works on just the highlighted text. Pick whichever matches the change you want to make. ## Reviewing Results The assistant streams its response into the window so you can read it as it writes. It is always a draft: - Nothing is applied until you choose **Insert**, **Replace**, or **Replace all**. - Use **Regenerate** to try again with the same instruction. - Use **Cancel** to close without changing anything. Always review AI output for accuracy before delivering a report to a client. The assistant helps you write faster, but you remain responsible for the content. ## Tips for Better Drafts - Be specific about tone, length, and audience, for example "two sentences, plain English, for an executive". - For findings, give it the key facts (what, where, impact) and let it structure the write-up. - If a first draft is close but not right, refine it with a follow-up selection edit rather than starting over. ## Next Steps - [Provider Modes](/docs/ai/provider-modes) to choose managed AI or bring your own. - [Privacy & Limits](/docs/ai/privacy-and-limits) to understand data handling and quotas. --- --- title: Billing description: Manage your Vulnsy subscription, view usage, change plans, and handle payments through Stripe — invoices, billing details, and seat management. --- import { Callout } from 'fumadocs-ui/components/callout'; Vulnsy uses [Stripe](https://stripe.com) for subscription management and payment processing. All billing is handled securely through Stripe's platform. ## Accessing Billing Navigate to the **Billing** section from the sidebar or admin area to view and manage your subscription. ## What You Can Do | Action | Description | |--------|-------------| | **View current plan** | See which plan your organization is on and what it includes | | **Check usage** | Monitor user count, storage usage, and other plan limits | | **Payment history** | View past invoices and payment records | | **Upgrade or downgrade** | Change your plan at any time to match your needs | | **Update payment method** | Change the card or payment method on file | ## How Billing Works - Subscriptions are billed monthly or annually - Upgrades take effect immediately - Downgrades take effect at the end of the current billing period - Invoices are generated automatically by Stripe You will receive email notifications from Stripe for upcoming charges, successful payments, and failed payment attempts. ## Next Steps - [Plans](/docs/billing/plans) -- compare available subscription tiers and features --- --- title: Plans description: Compare Vulnsy subscription plans — from solo consultants to enterprise security firms. See features, limits, and pricing for each tier. --- import { Callout } from 'fumadocs-ui/components/callout'; Vulnsy offers subscription plans for every stage of your security practice, from individual consultants to large organizations. ## Plan Tiers | Plan | Best For | |------|----------| | **Solo** | Individual consultants working independently | | **Team** | Small security teams (2--5 members) | | **Group** | Growing organizations scaling their pentest operations | | **SME** | Established security firms with larger teams and higher volume | | **Enterprise** | Large organizations needing custom pricing and dedicated support | ## What Every Plan Includes All plans include the core Vulnsy features: - Client management - Project and engagement tracking - Finding creation and library - Report generation and DOCX export - Client portal access ## What Scales with Your Plan Higher-tier plans provide increased limits and additional capabilities: | Feature | Scales With Plan | |---------|-----------------| | **Users** | More user seats as you move up tiers | | **Storage** | Increased file storage for evidence, templates, and documents | | **Modules** | Access to the client portal, QA, scoping, and disclosure modules | | **Support** | Priority support on higher tiers, dedicated support for Enterprise | ## Enterprise The Enterprise plan is designed for organizations with specific requirements: - Custom pricing based on your needs - Dedicated support channel - Custom onboarding and training - SLA guarantees - Contact [sales@vulnsy.com](mailto:sales@vulnsy.com) for details ## Trial New accounts can access a trial period to evaluate Vulnsy before committing to a paid plan. During the trial, you have access to all core features. No credit card is required to start. ## Changing Your Plan To upgrade or downgrade: 1. Go to **Billing** in the sidebar 2. Click **Change Plan** 3. Select the plan that fits your needs 4. Confirm the change Upgrades apply immediately. Downgrades take effect at the end of your current billing period. --- --- title: Clients Overview description: Manage the companies you perform penetration tests for, including contacts, addresses, and how client data flows into your reports. --- import { Callout } from 'fumadocs-ui/components/callout'; Clients represent the companies or organizations you perform penetration tests for. Every project in Vulnsy belongs to a client, and client data is automatically pulled into your exported reports through template tags. ## What Is a Client? A client record stores the key details about an organization you're engaged with. Each client has the following fields: | Field | Description | |-------|-------------| | **Company Name** | The legal or trading name of the organization | | **Contact Name** | Your primary point of contact at the company | | **Contact Email** | Email address for the primary contact | | **Contact Phone** | Phone number for the primary contact | | **Address** | The company's registered or office address | ## How Clients Fit into Vulnsy Clients sit at the top of the data hierarchy: - **Clients** contain one or more **Projects** - Each **Project** produces one or more **Reports** - Client details flow into reports via template tags during export When you export a report to DOCX, tags like `{client.name}`, `{client.contactName}`, and `{client.contactEmail}` are automatically replaced with the corresponding client data. You can also add your own **custom fields** to a client (label/value pairs) and loop over them in templates with `{#client.customFields}{label}: {value}{/}`. Keeping client records accurate ensures your exported reports always contain the correct company and contact information without manual editing. ## Next Steps - [Managing Clients](/docs/clients/managing-clients) — create, edit, and delete client records - [Creating Projects](/docs/projects/creating-projects) — link a project to a client - [Template Tags Reference](/docs/reports/export/template-tags) — full list of available client tags --- --- title: Managing Clients description: How to create, edit, and delete client records in Vulnsy, including how client data integrates with your pentest reports. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; ## Creating a Client ### Navigate to Clients Open the **Clients** section from the sidebar navigation. ### Add a New Client Click the **Add Client** button to open the client creation form. ### Fill In Client Details Complete the following fields: - **Company Name** — the organization's name as it should appear in reports - **Contact Name** — primary point of contact for the engagement - **Contact Email** — email address for correspondence - **Contact Phone** — phone number for the contact - **Address** — company address (used in report cover pages and headers) ### Save Click **Save** to create the client record. The client is now available for linking to projects. ## Editing a Client To update a client's details, navigate to the Clients section, select the client, and modify any of the fields. Changes are saved and will be reflected in any future report exports for projects linked to that client. Updating a client's details does not retroactively change previously exported DOCX files. Only new exports will use the updated information. ## Deleting a Client You can delete a client from the client detail view. Deleting a client also removes **all of its projects and reports** from your workspace — they are moved together into the **Deleted** area as a single batch. - **Recoverable at first.** An organization admin can restore the whole batch (client, projects, and reports together) from **Admin → Deleted**. - **Permanent deletion is final.** When an admin permanently deletes the batch, the client, its projects, reports, and all associated uploaded files (evidence, portal documents) are removed for good. Permanent deletion cannot be undone. Export any reports you need to keep before permanently deleting a client. ## Client Data in Reports Client information flows into your exported reports through template tags. When you build a DOCX template, you can use tags like: | Tag | Output | |-----|--------| | `{client.name}` | Company name | | `{client.contactName}` | Contact person's name | | `{client.contactEmail}` | Contact email address | | `{client.contactPhone}` | Contact phone number | | `{client.address}` | Company address | | `{#client.customFields}{label}: {value}{/}` | Any custom fields you've added to the client | See the [Template Tags Reference](/docs/reports/export/template-tags) for the full list of available tags. --- --- title: Creating Findings description: How to create vulnerability findings in Vulnsy, either as reusable library templates or directly within a report. --- import { Callout } from 'fumadocs-ui/components/callout'; You can create findings in two places: from the **Findings** page (to add to your library) or directly inside a **Report**. ## Creating a Library Finding 1. Navigate to the **Findings** page from the sidebar 2. Click **Add Finding** 3. Fill in the finding details (see fields below) 4. Click **Save** to add it to your organization's finding library ## Creating a Finding Inside a Report 1. Open a report and navigate to its findings section 2. Click **Add Finding** 3. Choose to create a new finding from scratch or import one from your library 4. Fill in or customize the details for this specific engagement Findings created directly in a report are not automatically added to your library. Save them to the library explicitly if you want to reuse them later. ## Finding Fields | Field | Required | Description | |-------|----------|-------------| | **Title** | Yes | A clear, concise name for the vulnerability | | **Severity** | Yes | Critical, High, Medium, Low, or Informational | | **Description** | Yes | Detailed writeup of the vulnerability and its impact. Rich text — bold, code blocks, lists, links, and pasted screenshots | | **Remediation** | Yes | Steps the client should take to fix the issue | | **CVSS** | No | CVSS 3.1 and/or 4.0 score — enter or build the vector and Vulnsy calculates the score | | **Affected assets** | No | The URLs, IPs, hostnames, or networks affected | | **References** | No | URLs to CVEs, OWASP, vendor advisories, or other external resources | | **Evidence** | No | Screenshots and an evidence narrative. See [Evidence](/docs/findings/evidence) | Library findings also belong to a **repository** — a named collection (e.g. "AppSec", "NetPen") that keeps your library organized. See [Finding Library](/docs/findings/finding-library). ## Rich Text Editor The description, remediation, and evidence narrative fields use a rich text editor. You can: - Format text with bold, italic, and inline code - Add code blocks with syntax highlighting - Create ordered and unordered lists - Insert links and tables - Paste content directly from other tools When pasting content from external sources, review the formatting. The editor preserves most HTML formatting, but complex layouts may need adjustment. ## Saving to Your Library When you create a finding you want to reuse across engagements, save it to your organization's [finding library](/docs/findings/finding-library). This makes it available to all team members and can be imported into future reports. --- --- title: Evidence description: Attach screenshots and images to findings as proof of discovered vulnerabilities. Evidence is embedded in exported reports. --- import { Callout } from 'fumadocs-ui/components/callout'; Evidence is visual proof attached to a finding — typically screenshots demonstrating that a vulnerability exists and can be exploited. Evidence appears in your exported reports alongside the finding it belongs to. ## Adding Evidence to a Finding 1. Open a finding (either in a report or in the library) 2. Scroll to the **Evidence** section 3. Upload an image file or paste a screenshot directly from your clipboard 4. Add a **description** explaining what the screenshot shows You can attach multiple pieces of evidence to a single finding. ## Evidence Fields Each piece of evidence has the following properties: | Field | Description | |-------|-------------| | **fileName** | The name of the uploaded image file | | **Description** | A caption explaining what the evidence shows | | **Image data** | The image itself (stored and embedded in exports) | ## Supported Formats Vulnsy accepts **PNG, JPG/JPEG, GIF, WebP, and SVG** images, up to 50 MB per file. - **PNG** — recommended for screenshots - **JPG / JPEG** — suitable for photos and lower-fidelity images PNG is the best format for screenshots of application interfaces. It preserves text clarity and supports transparency. ## Evidence in Exported Reports Evidence is embedded directly into the exported DOCX file. In your report template, evidence is rendered using the `{%image}` tag nested inside the findings loop: ``` {#findings} {findingId} - {title} Severity: {severity} {#evidence} {%image} {caption} {/evidence} {/findings} ``` The `{#evidence}` block loops over all evidence items attached to each finding. Inside the loop: | Tag | Output | |-----|--------| | `{%image}` | The image itself, embedded in the document | | `{caption}` | "Figure N - description" with an automatic figure number | | `{description}` | Just the caption text, without the figure number | | `{@captionXml}` | A pre-formatted Word caption (Caption style + auto-numbering field) | The `{#evidence}` loop must be nested inside the `{#findings}` loop. Evidence belongs to a specific finding and cannot be rendered outside of that context. ## Tips for Good Evidence - Capture the full context — include the URL bar, request/response, or relevant UI elements - Highlight or annotate the key area of the screenshot so reviewers can quickly identify the issue - Write clear descriptions: "Reflected XSS payload executing in the search results page" is more useful than "Screenshot 1" - Keep file sizes reasonable — crop screenshots to show only what is relevant --- --- title: Finding Library description: Manage a centralized repository of reusable vulnerability templates organized by category, shared across your organization. --- import { Callout } from 'fumadocs-ui/components/callout'; The finding library is a centralized repository of vulnerability templates. Instead of writing the same finding from scratch on every engagement, build your library once and import findings into reports as needed. ## How the Library Works Your library contains two types of templates: | Template Type | Visibility | Description | |---------------|------------|-------------| | **Global templates** | All organizations | Shared by Vulnsy. A curated set of common vulnerability findings available to every workspace | | **Organization templates** | Your workspace only | Custom findings created by your team. Private to your organization | ## Browsing and Searching From the **Findings** page, you can: - **Search** by finding title using the search bar - **Filter by severity** — show only Critical, High, Medium, Low, or Informational findings - **Browse by repository** — narrow results to a collection like AppSec, NetPen, Cloud, or any repository you've created ## Importing Findings into a Report 1. Open a report and navigate to its findings section 2. Click **Add Finding** 3. Select **Import from Library** 4. Search or browse for the finding you need 5. Click to import it into the report 6. Customize the imported finding for this specific engagement (adjust description, evidence, etc.) Importing a finding creates a copy in the report. Changes you make to the imported finding only affect that report, not the original library template. ## Managing Library Findings ### Adding Findings Create new library findings from the **Findings** page by clicking **Add Finding** and filling in the details. See [Creating Findings](/docs/findings/creating-findings) for the full walkthrough. ### Editing Findings You can edit any organization template at any time. Update the title, severity, description, or any other field. Editing a library finding does **not** retroactively update reports that already contain a copy of that finding. Each report holds its own independent copy from the moment of import. ### Deleting Findings Removing a finding from the library does not affect reports that have already imported it. The report copies are independent. ## Building an Effective Library - Start with the global templates provided by Vulnsy and customize them for your methodology - After each engagement, save any new one-off findings to the library for future reuse - Use consistent naming conventions so findings are easy to search (e.g. "SQL Injection — Login Form" rather than "SQLi issue") - Keep descriptions generic enough to apply across clients, then customize per-report after importing --- --- title: Findings Overview description: Findings are the core unit of a pentest report in Vulnsy. Each finding represents a discovered vulnerability with severity, evidence, and remediation guidance. --- import { Callout } from 'fumadocs-ui/components/callout'; Findings are the building blocks of every pentest report. Each finding represents a single vulnerability discovered during an engagement, complete with a description, severity rating, evidence, and remediation guidance. ## What Is a Finding? A finding documents a specific security issue. Every finding contains the following fields: | Field | Description | |-------|-------------| | **Title** | Short name identifying the vulnerability | | **Severity** | Critical, High, Medium, Low, or Informational | | **Description** | Detailed explanation of the vulnerability, how it was identified, and its impact | | **Remediation** | Recommended steps to fix or mitigate the vulnerability | | **Status** | Current state — Open, In Progress, Remediated, or Accepted Risk | | **CVSS** | Optional CVSS 3.1 and/or 4.0 score with full vector support | | **Affected assets** | The URLs, IPs, hostnames, or networks the issue applies to | | **References** | Links to CVEs, OWASP entries, or other external resources | | **Evidence** | Screenshots and an evidence narrative proving the vulnerability exists | ## Two Ways to Use Findings Vulnsy supports two workflows for managing findings: - **Library findings** — Reusable vulnerability templates stored in your organization's [finding library](/docs/findings/finding-library). Import them into any report and customize the details for that specific engagement. - **One-off findings** — Custom findings created directly inside a report. Useful for unique issues that don't need to be templated. Library findings save significant time on recurring assessments. Build your library once, then pull findings into reports with a few clicks. ## Organizing the Library Library findings are organized into **repositories** — named collections you control. Most teams organize by assessment type, for example: - **AppSec** — XSS, SQLi, CSRF, authentication flaws, etc. - **NetPen** — misconfigurations, unpatched services, network-level issues - **Mobile** — insecure storage, certificate pinning, platform-specific issues - **Cloud** — IAM misconfigurations, exposed storage, serverless risks You can create, rename, and reorganize repositories to match your own methodology. ## Next Steps - [Creating findings](/docs/findings/creating-findings) — learn how to add findings to reports and your library - [Finding library](/docs/findings/finding-library) — manage reusable vulnerability templates - [Evidence](/docs/findings/evidence) — attach screenshots and proof to your findings - [Severity levels](/docs/findings/severity-levels) — understand how severity ratings work --- --- title: Severity Levels description: Understanding Vulnsy's five severity levels — Critical, High, Medium, Low, and Informational — and how they affect report output. --- import { Callout } from 'fumadocs-ui/components/callout'; Every finding in Vulnsy is assigned a severity level. Severity communicates the risk a vulnerability poses to the client and determines the order findings appear in exported reports. ## Severity Definitions | Severity | Description | Example | |----------|-------------|---------| | **Critical** | Immediate risk of data breach or full system compromise. Exploitation is trivial and may require no authentication. | Unauthenticated remote code execution, SQL injection exposing entire database | | **High** | Significant security impact. Exploitation is feasible with moderate effort or requires limited prerequisites. | Stored XSS in admin panel, privilege escalation to admin role | | **Medium** | Moderate risk. Exploitation may require specific conditions, user interaction, or chained vulnerabilities. | CSRF on sensitive actions, missing rate limiting on login | | **Low** | Minor security concern with limited impact. Difficult to exploit or requires significant prerequisites. | Verbose error messages, missing security headers with low impact | | **Informational** | No direct security impact. Best practice recommendation or observation for hardening. | Software version disclosure, use of deprecated TLS cipher suites | ## How Severity Affects Reports - **Sort order** — When findings are sorted by severity in an exported report, they appear in order from Critical down to Informational - **Executive summary** — Severity counts (e.g. "3 Critical, 5 High, 8 Medium") are commonly included in report summaries to give clients a quick risk overview - **Prioritization** — Clients use severity to prioritize remediation efforts, so accurate ratings are essential Be consistent with severity ratings across engagements. If your team rates missing HSTS as Low on one report, it should be Low on every report unless specific circumstances change the risk. ## CVSS Scores Vulnsy's severity levels can be complemented by **CVSS (Common Vulnerability Scoring System)** scores. CVSS provides a numerical score (0.0 -- 10.0) that maps to severity: | CVSS Score | Severity | |------------|----------| | 9.0 -- 10.0 | Critical | | 7.0 -- 8.9 | High | | 4.0 -- 6.9 | Medium | | 0.1 -- 3.9 | Low | | 0.0 | Informational | CVSS scores are optional. Many pentest teams prefer qualitative severity ratings based on real-world exploitability and business context rather than relying solely on CVSS. ## Choosing the Right Severity When assigning severity, consider: - **Exploitability** — How easy is it to exploit? Does it require authentication, special tools, or user interaction? - **Impact** — What is the worst-case outcome? Data breach, service disruption, or information disclosure? - **Scope** — Does exploiting this issue affect other systems or components beyond the vulnerable one? - **Business context** — A medium-severity technical finding on a payment processing system may warrant a higher effective rating due to regulatory impact --- --- title: Core Concepts description: Understand Vulnsy's data model — organizations, clients, projects, findings, reports, templates, and how they fit together. --- import { Callout } from 'fumadocs-ui/components/callout'; This page covers the key entities in Vulnsy and how they relate to each other. Understanding this data model will help you navigate the platform efficiently. ## Organizations Every Vulnsy account belongs to an **organization**. Your organization is your workspace — it has its own clients, projects, findings, templates, and team members, and its own login address (e.g. `yourteam.vulnsy.com`). Data is fully isolated between organizations. ## Clients A **client** represents a company or entity you are performing security testing for. Clients sit at the top of your engagement hierarchy. Each client can have multiple projects under it, giving you a historical record of all testing performed for that organization. ## Projects A **project** is an individual pentest engagement. Projects belong to a client and define the scope and timeline of the work. Each project includes: - **Start and end dates** — the engagement window. - **Project type** — categorizes the engagement. Supported types: | Type | Description | |------|-------------| | `web_app` | Web application testing | | `infrastructure` | Network and infrastructure testing | | `mobile` | Mobile application testing | | `cloud` | Cloud environment testing | | `api` | API security testing | | `iot` | IoT device and firmware testing | ## Findings A **finding** is a single vulnerability or observation discovered during testing. Findings are the core unit of work in Vulnsy. Each finding includes: | Field | Description | |-------|-------------| | **Severity** | `critical`, `high`, `medium`, `low`, or `info` | | **Description** | Technical explanation of the vulnerability and its impact | | **Remediation** | Recommended fix or mitigation | | **CVSS score** | Optional CVSS 3.1 and/or 4.0 scoring with full vector support | | **Affected assets** | The URLs, IPs, or hostnames the issue applies to | | **Evidence** | Screenshots and supporting narrative proving the finding | Findings can be created from scratch within a project, or pulled from your **finding library** — a reusable collection of common vulnerabilities that you maintain across engagements. Building a finding library saves significant time on repeat engagement types. Write a finding once, reuse it across projects, and customize the evidence per engagement. ## Reports A **report** is the deliverable you send to the client. In Vulnsy, reports are composed of one or more **tabs**. ### Report Tabs Each tab represents a distinct section of the report — for example, "Web Application" and "Infrastructure" in a combined engagement. Each tab has: - Its own set of **assigned findings**. - **Narrative sections** — executive summary, scope, methodology, and other written content specific to that test area. This structure lets you build a single report that covers multiple testing areas while keeping the content organized. ### Export Tag Prefix Each report tab has an **export tag prefix** (e.g., `web`, `infra`). This prefix scopes the template tags during export so that data from different tabs maps to the correct placeholders in your Word template. For example, a tab with prefix `web` exposes its findings as `{#web.findings}…{/}` and its narrative sections as `{~web.sections.introduction}`, while a tab with prefix `infra` uses `{#infra.findings}…{/}`. This is what makes multi-tab exports work — each tab's data stays in its own lane. Export tag prefixes must be unique within a report. If two tabs share the same prefix, the export will produce unexpected results. ## Templates **Templates** are Word documents (`.docx`) that define the layout and formatting of your exported reports. They contain placeholder tags that Vulnsy replaces with actual report data during export. You can: - Use Vulnsy's **default templates** to get started immediately. - Upload **custom templates** with your own branding, formatting, and tag placement. - Maintain **multiple templates** for different report types or client requirements. For full details on building templates and the available tag syntax, see the [Template Tag Reference](/docs/reports/export/template-tags). ## How It All Fits Together ``` Organization └── Client └── Project (type, dates) ├── Findings (severity, description, impact, remediation, evidence) └── Report ├── Tab 1 (prefix: "web") │ ├── Assigned Findings │ └── Narrative Sections ├── Tab 2 (prefix: "infra") │ ├── Assigned Findings │ └── Narrative Sections └── Export → Template (.docx) → Final Report ``` This hierarchy is the backbone of Vulnsy. Once you understand how these pieces connect, the rest of the platform is straightforward. --- --- title: Getting Started description: Everything you need to start using Vulnsy for pentest report management — what it is, who it's for, and what you need. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Cards, Card } from 'fumadocs-ui/components/card'; Vulnsy is a SaaS penetration testing report management platform. It gives security professionals a structured workflow for managing clients, engagements, findings, and report generation — replacing the spreadsheets, shared drives, and manual Word document editing that slow most teams down. ## Who Vulnsy Is For - **Independent pentesters** — manage your client base, reuse findings across engagements, and produce consistent, professional reports. - **Security consultants** — collaborate with team members on projects, maintain a shared finding library, and deliver reports through a client portal. - **Security teams** — centralize your pentest operations under one organization with role-based access, standardized templates, and an audit trail of engagements. ## What You Need Vulnsy runs entirely in the browser. There is nothing to install. | Requirement | Details | |-------------|---------| | Browser | Any modern browser (Chrome, Firefox, Safari, Edge) | | Account | Sign up at [vulnsy.com](https://vulnsy.com) | | Template (optional) | A `.docx` Word template for custom report exports | Vulnsy provides default report templates out of the box. You can start exporting reports immediately and customize templates later. ## Next Steps --- --- title: Quickstart description: Go from sign-up to exported report in seven steps. Create a client, add findings, build a report, and export a professional deliverable. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; This guide walks you through the complete workflow — from creating your account to exporting a finished report. You can complete it in under five minutes. ### Sign up at vulnsy.com Go to [vulnsy.com](https://vulnsy.com) and create your account. You will be prompted to set up your organization during onboarding. This organization is your workspace — all clients, projects, and reports live here. ### Create your first client Navigate to **Clients** in the sidebar and click **New Client**. Enter the company name and any relevant contact details. The client record is the top-level container for all engagements with that company. ### Create a project under that client Open your new client and click **New Project**. Fill in: - **Project name** — e.g., "Q1 2026 Web Application Assessment" - **Project type** — select the engagement type (web app, infrastructure, mobile, cloud, API, or IoT) - **Start and end dates** — the engagement window This project is where you will track findings and build your report. ### Add findings Open the project and navigate to the **Findings** section. You have two options: - **From the finding library** — search your reusable finding library and import existing vulnerability descriptions. Customize the evidence and details for this specific engagement. - **Create custom** — write a finding from scratch with severity, description, remediation, and evidence. Add as many findings as your assessment requires. Even on your first engagement, it is worth writing findings with reuse in mind. Well-written findings in your library will save hours on future projects. ### Create a report and assign findings Go to the **Reports** section within your project and click **New Report**. Set up your report structure: 1. **Add one or more tabs** — each tab represents a section of your report (e.g., "Web Application", "Infrastructure"). Give each tab an **export tag prefix** (e.g., `web`, `infra`). 2. **Assign findings to each tab** — select which findings belong in which section. 3. **Write narrative sections** — add executive summary, scope, methodology, and any other written content to each tab. ### Upload a DOCX template (or use a default) Navigate to your report's export settings. You can either: - **Use a default template** — Vulnsy includes built-in templates that work immediately. - **Upload a custom template** — upload your own branded `.docx` file with placeholder tags that map to your report data. If you are just getting started, use the default template first. You can switch to a custom template at any time. See the [Template Tag Reference](/docs/reports/export/template-tags) for details on building your own. ### Export your report Click **Export** on your report. Vulnsy merges your findings, narrative content, and metadata into the selected template and generates a polished `.docx` file ready for client delivery. Review the output document. If anything needs adjustment, update the report content or template and re-export — there is no limit on exports. ## What's Next Now that you have the basic workflow down, explore the platform further: - [Managing Clients](/docs/clients) — organize contacts and engagement history. - [Working with Findings](/docs/findings) — build your reusable finding library. - [Report Building](/docs/reports) — multi-tab reports, narrative sections, and advanced export options. - [Creating Templates](/docs/reports/export/creating-templates) — build custom DOCX templates with your own branding. --- --- title: Welcome to Vulnsy description: Vulnsy is a professional pentest reporting platform that helps security teams manage engagements, findings, and generate client-ready reports. --- import { Cards, Card } from 'fumadocs-ui/components/card'; Vulnsy is a penetration testing report management platform built for security consultants and teams. It handles the full lifecycle from scoping engagements through to delivering polished reports to your clients. ## Quick Links ## What Vulnsy Does - **Client management** — track companies, contacts, and engagement history - **Project scoping** — define engagements with types, dates, and team assignments - **Findings library** — reusable vulnerability templates organized by category - **Multi-tab reports** — build reports with separate sections for different test areas - **Automated DOCX export** — generate professional reports from Word templates with dynamic data - **Search and replace** — bulk variable replacement across report content before export - **Client portal** — share reports with clients and manage QA review workflows - **Team collaboration** — role-based access control for admins, consultants, and external collaborators ## How This Documentation Is Organized | Section | What You'll Find | |---------|-----------------| | [Getting Started](/docs/getting-started) | Workspace setup, core concepts, creating your first report | | [Clients](/docs/clients) | Managing client companies and contacts | | [Projects](/docs/projects) | Creating and managing pentest engagements | | [Findings](/docs/findings) | Building your vulnerability library | | [Reports](/docs/reports) | Building reports, exporting, and template tags | | [AI Assistant](/docs/ai) | Drafting with AI, provider modes, privacy and limits | | [Client Portal](/docs/portal) | Sharing reports and QA workflows | | [Admin](/docs/admin) | Permissions, templates, and organization settings | | [Billing](/docs/billing) | Subscription plans and usage | | [Troubleshooting](/docs/troubleshooting) | Common issues and solutions | --- --- title: Client Portal description: Share reports and documents with your clients securely through the Vulnsy client portal — branded delivery, controlled access, and full audit trails. --- import { Callout } from 'fumadocs-ui/components/callout'; The client portal gives your clients a secure, read-only view of the reports and documents you share with them. Instead of emailing attachments back and forth, you upload documents to the portal and clients access them through their own login. ## What the Portal Provides | Feature | Description | |---------|-------------| | **Report sharing** | Upload exported reports and supporting documents for client access | | **Secure access** | Clients log in with their own credentials and only see documents shared with them | | **QA workflow** | Route reports through a review cycle before sharing with clients | | **Download** | Clients can download shared documents directly from the portal | ## Enabling the Portal The client portal is an optional module included with your subscription plan. When it is enabled for your workspace: 1. Invite client users by assigning them the **Client** role from **Admin > Users** 2. Client users log in to your workspace and see only the portal If the portal is not available on your workspace, contact [support@vulnsy.com](mailto:support@vulnsy.com) about your plan. Clients with the **Client** role can only access the portal. They cannot see your internal projects, findings, or other organization data. ## How It Works 1. Complete your pentest report in Vulnsy 2. Export the report as a DOCX document 3. Upload the document to the portal for the relevant client 4. The client receives an email notification with a link to view the document 5. The client logs in and downloads the report ## Next Steps - [Sharing Reports](/docs/portal/sharing-reports) -- upload and manage documents in the portal - [QA Workflow](/docs/portal/qa-workflow) -- review and approve reports before client delivery --- --- title: QA Workflow description: Route reports through a QA review cycle before delivering them to clients — assign reviewers, track approvals, and gate publication on the portal. --- import { Callout } from 'fumadocs-ui/components/callout'; The QA workflow ensures every report meets your quality standards before it reaches the client. Reports move through defined statuses, and reviewers can flag issues or request changes before final delivery. ## Report Statuses Every report follows a three-stage lifecycle: | Status | Description | |--------|-------------| | **Draft** | The report is being written. Findings, narrative sections, and evidence are still being added or edited. | | **Review** | The report is ready for internal review. A reviewer examines the content for accuracy, completeness, and quality. | | **Final** | The report has been approved and is ready for client delivery. | ## Review Process 1. The consultant completes the report and sets the status to **Review** 2. A reviewer is assigned to examine the report 3. The reviewer checks findings, narrative content, evidence, and formatting 4. If changes are needed, the reviewer flags specific issues and the status returns to **Draft** 5. Once all issues are resolved, the reviewer approves the report and sets it to **Final** 6. The finalized report is exported and shared through the portal Only users with the appropriate permissions (typically **Admin** or **Consultant** roles) can change report statuses and approve reports. ## Best Practices - **Establish review criteria** -- define what reviewers should check (e.g., severity accuracy, evidence quality, remediation clarity) - **Use the Draft-Review-Final cycle consistently** -- avoid sharing reports that have not been through review - **Assign dedicated reviewers** -- separate the person writing the report from the person reviewing it Treat **Final** as locked by convention — if further changes are needed after finalization, move the report back to **Draft** so reviewers know it needs another pass. --- --- title: Sharing Reports description: Upload reports and documents to the client portal so your clients can securely view and download them, with access controls, expiry, and audit history. --- import { Callout } from 'fumadocs-ui/components/callout'; Once you have exported a report from Vulnsy, you can share it with your client through the portal. Documents are uploaded to the portal, stored securely, and made available only to the intended client. ## Sharing a Document 1. Export your report as a DOCX file from the report page 2. Navigate to the client's portal section 3. Upload the document 4. Select which client contacts should have access 5. The selected clients receive an email notification with a link to the portal ## Access Control You control exactly which clients see which documents. Each uploaded document is scoped to a specific client, and only users with portal access for that client can view it. | Control | Description | |---------|-------------| | **Per-client scoping** | Documents are linked to a specific client | | **Contact selection** | Choose which client contacts receive access | | **Email notifications** | Clients are notified automatically when new documents are shared | Only users with the **Client** role can access the portal. Assign this role from **Admin > Users**. ## Document Storage All portal documents are stored securely in AWS S3 with full tenant isolation. Each organization's files are kept separate, and access is enforced at the application level. - Documents are encrypted at rest - Tenant isolation ensures no cross-organization access - Storage usage is visible in **Admin > Organization Settings** Large file uploads are subject to your organization's storage limits. Check your current usage in **Admin > Organization Settings** if uploads fail. ## Managing Shared Documents From the portal management view, you can: - View all documents shared with a client - Remove documents that are no longer relevant - Re-share documents with additional contacts --- --- title: Creating Projects description: How to create and configure pentest engagement projects in Vulnsy, including setting types, dates, and assigning team members. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; ## Creating a New Project ### Select a Client Navigate to the **Projects** section and click **New Project**. Choose the client this engagement belongs to. If the client does not exist yet, you will need to [create the client first](/docs/clients/managing-clients). ### Set Project Details Fill in the core project fields: - **Name** — a clear, descriptive name for the engagement (e.g., "Q1 2026 External Infrastructure Assessment") - **Description** — summarize the scope and objectives - **Type** — select the assessment category: `web_app`, `infrastructure`, `mobile`, `cloud`, `api`, or `iot` ### Set Engagement Dates Define the **Start Date** and **End Date** for the testing window. These dates are used in report exports via the `{project.startDate}` and `{project.endDate}` template tags, and can be reformatted at export time (e.g. `{project.startDate | date:"UK"}`). ### Assign Operators Add team members (consultants) who will work on this engagement. Operators assigned to a project can access its reports and findings. ### Save the Project Click **Save** to create the project. You can now begin adding reports and findings. ## Editing a Project Open a project from the Projects list to modify any of its details. You can update the name, description, type, dates, or team assignments at any time. Changing the project type or dates will be reflected in future report exports. Previously exported DOCX files are not affected. ## Project Data in Reports Project information is available in DOCX exports through template tags: | Tag | Output | |-----|--------| | `{project.name}` | Project name | | `{project.description}` | Project description | | `{project.type}` | Assessment type | | `{project.startDate}` | Engagement start date | | `{project.endDate}` | Engagement end date | | `{#project.customFields}{label}: {value}{/}` | Any custom fields you've added to the project | These tags are replaced automatically during export, so your report templates stay reusable across engagements. ## Managing Team Assignments Operators are the consultants assigned to a project. When you assign an operator: - They gain access to all reports and findings within the project - Their details can be included in report exports via the `{#consultants}…{/}` loop or the pre-joined `{consultantNames}` tag - You can add or remove operators at any point during the engagement See the [Template Tags Reference](/docs/reports/export/template-tags) for the full list of project and consultant tags. --- --- title: Projects Overview description: Understand how projects work in Vulnsy, representing individual pentest engagements with types, dates, team assignments, and linked reports. --- import { Callout } from 'fumadocs-ui/components/callout'; A project in Vulnsy represents a single penetration testing engagement. Projects belong to a client and contain all the reports, findings, and scope details for that engagement. ## What Is a Project? Each project captures the key details of an engagement: | Field | Description | |-------|-------------| | **Name** | A descriptive name for the engagement | | **Description** | Summary of the engagement scope and objectives | | **Client** | The client company this project belongs to | | **Type** | The category of assessment being performed | | **Status** | Current state of the engagement | | **Start Date** | When testing begins | | **End Date** | When testing is expected to conclude | | **Operators** | Team members (consultants) assigned to the project | ## Project Types Vulnsy supports the following project types: | Type | Description | |------|-------------| | `web_app` | Web application penetration test | | `infrastructure` | Internal or external infrastructure assessment | | `mobile` | Mobile application security testing | | `cloud` | Cloud environment security review | | `api` | API security assessment | | `iot` | IoT device and firmware testing | The project type is included in report exports via the `{project.type}` template tag, so it appears in your deliverables automatically. ## How Projects Fit into Vulnsy Projects connect clients to reports: - A **Client** has one or more **Projects** - A **Project** contains **Findings** (vulnerabilities) and one or more **Reports** - Findings are assigned to report tabs, so the same project finding can appear in a draft report and a retest report Project details like name, type, and dates are available as template tags in your DOCX exports, reducing manual data entry when generating reports. ## Next Steps - [Creating Projects](/docs/projects/creating-projects) — set up a new engagement - [Scoping Calculator](/docs/projects/scoping) — estimate effort and costs - [Reports](/docs/reports) — build and export reports within a project --- --- title: Scoping Calculator description: Use Vulnsy's scoping calculator to estimate engagement effort, costs, and generate figures for proposals and statements of work. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; The scoping calculator helps you estimate the effort and cost of a penetration testing engagement. It generates figures you can use in proposals, statements of work (SOWs), and client communications. ## How It Works The scoping calculator uses your day rate and estimated effort to produce a cost estimate: | Input | Description | |-------|-------------| | **Day Rate** | The daily cost per consultant (in your chosen currency) | | **Testing Days** | The estimated number of days of hands-on testing | | **Reporting Days** | The estimated number of days for writing and QA | The total estimated days (testing + reporting) multiplied by the day rate gives the engagement cost. Vulnsy can also generate **Statement of Work (SOW) text** from your scoping inputs, ready to paste into a proposal. ## Using the Scoping Calculator ### Open the Scoping Section Navigate to a project and open the **Scoping** tab. ### Set the Day Rate Enter the daily rate for the engagement. This is typically the per-consultant cost charged to the client. ### Define Testing and Reporting Days Set the estimated testing days and reporting days. For testing effort, consider factors like: - Size and complexity of the target environment - Number of applications, hosts, or endpoints in scope - Depth of testing required (e.g., authenticated vs. unauthenticated) Reporting days cover writeup, evidence preparation, and QA review. ### Review the Estimate The calculator displays the total cost based on your inputs. Use this figure in your proposal or SOW. The scoping calculator is a planning tool. It does not affect project billing or invoicing — it simply provides an estimate you can share with clients during the pre-engagement phase. ## When to Use Scoping The scoping calculator is useful at several points in the engagement lifecycle: - **Pre-engagement** — generate cost estimates for proposals and SOWs - **Scope changes** — recalculate costs when the client adds or removes targets - **Internal planning** — estimate resource allocation and consultant availability Keep scoping estimates updated as the engagement evolves. If the scope changes mid-project, revisit the calculator to ensure your estimates remain accurate. --- --- title: Creating Templates description: Build Word DOCX templates for Vulnsy report export — tag placement, testing, and uploading. Step-by-step guide with examples for each section. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; Vulnsy templates are `.docx` files with placeholder tags. Design your layout in Word, add tags where dynamic data should appear, then upload. Familiarise yourself with the [Template Tags](/docs/reports/export/template-tags) reference first. ## Creating Your Template ### Create a New Word Document and Disable Spell Check Open Word and create a blank `.docx` document. Before adding any tags, disable spell check — it silently splits tags across XML nodes, breaking them. **File → Options → Proofing** — uncheck "Check spelling as you type" and "Mark grammar errors as you type". This is the most common cause of broken templates. With spell check enabled, Word may split `{client.name}` into `{client` + `.name}` in the underlying XML. ### Add Static Content Add your report structure: cover page, logo, section headings, headers/footers, page numbers, table styles, and branding. ### Add Template Tags Type each tag in **one continuous motion** — opening `{` to closing `}` without stopping. Do not copy/paste tags or edit them after typing. ``` {report.title} Version {report.version} | Status: {report.status} Generated: {metadata.generatedDate} by {metadata.generatedBy} Prepared by {organization.name} for {client.name} Contact: {client.contactName} ({client.contactEmail}) Project: {project.name} Testing Period: {project.startDate} — {project.endDate} EXECUTIVE SUMMARY {~report.executiveSummary} METHODOLOGY {~report.methodology} ``` ### Add Findings Loop Loop opening/closing tags must each be in their own paragraph. ``` {#findings} {findingId} - {title} Severity: {severity} — CVSS: {cvss.score} {~description} Remediation: {~remediation} {#evidence} {%image} {caption} {/evidence} {/findings} ``` `{#findings}`, `{/findings}`, `{#evidence}`, `{/evidence}`, and `{%image}` must each be alone in their own paragraph. ### Add Consultants and Tabs (Optional) ``` {#consultants} {name} — {email} — {jobTitle} {/consultants} ``` ``` {#tabs} {name} ({exportTagPrefix}) {/tabs} ``` ### Save and Upload Save as `.docx` (not `.doc` or `.dotx`). Navigate to **Admin → Report Templates**, upload the file, give it a name, and save. ### Test with a Real Report Export a report using your template and verify: - [ ] All tags replaced with real values (no raw `{tag}` text remaining) - [ ] Findings loop generates entries for each finding - [ ] Evidence images appear within findings - [ ] Consultants list renders correctly - [ ] Formatting, headers/footers, and page breaks look correct - [ ] Conditional sections show/hide as expected ## Tag Placement Rules | Tag Type | Placement | |----------|-----------| | Inline tags (`{report.title}`) | Can be mixed with text | | Loop tags (`{#findings}`, `{/findings}`) | Own paragraph | | Image tags (`{%image}`) | Own paragraph | | Conditional tags (`{#field}`, `{/field}`) | Own paragraph | ## Troubleshooting | Problem | Fix | |---------|-----| | Tag shows raw `{tag}` text | Delete and retype in one motion — XML is likely split | | Loop produces no output | Ensure loop tags are in their own paragraphs. Verify data exists. | | Image not appearing | Put `{%image}` on its own line. Check evidence has uploaded images. | | Export fails | Check every `{#loop}` has a matching `{/loop}`. Check for typos. | ## Next Steps - [Template Tags](/docs/reports/export/template-tags) — full tag reference - [Export Tag Prefixes](/docs/reports/export/export-tag-prefix) — scope data in multi-tab reports - [Search & Replace](/docs/reports/export/search-replace) — replace variables before export --- --- title: Export Tag Prefixes description: How export tag prefixes scope template data to specific tabs in multi-tab Vulnsy reports, enabling structured DOCX exports across multiple testing areas. --- import { Callout } from 'fumadocs-ui/components/callout'; When a report has multiple tabs — for example, "Web Application" and "Infrastructure" — each tab's data needs to be distinguishable in the exported document. Export tag prefixes solve this by scoping each tab's findings and narrative content under a unique identifier. ## What Is an Export Tag Prefix? Every report tab has an **exportTagPrefix** — a short label like `web`, `infra`, or `mobile` that identifies that tab's data during export. The prefix appears as a badge or chip next to the tab name in the export UI, making it easy to see which prefix maps to which tab. | Tab Name | Export Tag Prefix | What It Scopes | |----------|------------------|----------------| | Web Application | `web` | All findings and narrative content from this tab | | Infrastructure | `infra` | All findings and narrative content from this tab | | Mobile App | `mobile` | All findings and narrative content from this tab | You set the export tag prefix when creating or editing a tab. It can be any short string that makes sense for your engagement. ## How Prefixes Work in Templates When you export a multi-tab report, the `{#tabs}` loop in your template iterates through each included tab. Each tab carries its own findings, narrative sections, and the prefix identifier. ``` {#tabs} Testing Area: {name} Prefix: {exportTagPrefix} Findings for this tab: {#findings} {order}. {title} — {severity} {~description} {/findings} {/tabs} ``` In this example, the template loops through each tab and renders that tab's findings within its section. The `{exportTagPrefix}` tag outputs the prefix value itself, which you can use as a label or reference ID in the document. ## Finding IDs and Tab Scoping Each tab also has a **findingIdPrefix** that controls how finding reference IDs are generated. By default, the prefix is `REF`, producing IDs like `REF-001`, `REF-002`, etc. When you customize the finding ID prefix per tab, findings are scoped accordingly: | Tab | Finding ID Prefix | Example Finding IDs | |-----|------------------|---------------------| | Web Application | `WEB` | `WEB-001`, `WEB-002`, `WEB-003` | | Infrastructure | `INFRA` | `INFRA-001`, `INFRA-002` | | Mobile App | `MOB` | `MOB-001`, `MOB-002` | This makes it clear in the final report which testing area each finding belongs to, even when all findings are listed together. ## Export Options with Multiple Tabs When exporting a multi-tab report, you choose which tabs to include: | Export Option | Behavior | |---------------|----------| | **All tabs** | Every tab is included. The `{#tabs}` loop iterates through all of them, and all findings from all tabs appear in the document. | | **Single tab** | Only the selected tab's findings and narrative content appear. Report-level fields (title, client, project) are still included. | | **Custom selection** | You pick specific tabs to include. Only selected tabs appear in the `{#tabs}` loop and only their findings are exported. | When exporting a single tab, report-level fields like `{report.title}`, `{client.name}`, and `{project.name}` are always available — they are not scoped to a specific tab. Only findings and narrative sections are tab-specific. ## Setting Up Prefixes 1. Open your report and navigate to the tab you want to configure 2. Click the tab settings or edit the tab 3. Set the **Export Tag Prefix** to a short, descriptive label (e.g., `web`, `infra`, `api`) 4. Optionally set a custom **Finding ID Prefix** (e.g., `WEB`, `INFRA`, `API`) 5. Save the tab Repeat for each tab in your report. Each tab should have a unique prefix to avoid confusion in the exported document. Use unique prefixes for each tab within the same report. Duplicate prefixes will make it difficult to distinguish between tabs in the exported document. ## Example: Multi-Tab Report Consider a report with two tabs: **Tab 1: Web Application** - Export Tag Prefix: `web` - Finding ID Prefix: `WEB` - Findings: SQL Injection (WEB-001), XSS (WEB-002), CSRF (WEB-003) **Tab 2: Infrastructure** - Export Tag Prefix: `infra` - Finding ID Prefix: `INFRA` - Findings: Open Ports (INFRA-001), Weak SSH Config (INFRA-002) When exported with the template shown above, the document would contain two sections — one for Web Application with three findings, and one for Infrastructure with two findings — each clearly labeled with its prefix. ## Next Steps - [Template Tags](/docs/reports/export/template-tags) — full reference of all available template tags - [Search & Replace](/docs/reports/export/search-replace) — replace variables across report content before export - [Creating Templates](/docs/reports/export/creating-templates) — build Word templates that use tab loops and prefixes --- --- title: Report Export Overview description: How Vulnsy generates professional DOCX pentest reports from Word templates using placeholder tags, variable replacement, and flexible export options. --- import { Callout } from 'fumadocs-ui/components/callout'; Vulnsy's export system generates professional DOCX reports from Word templates. You define a template once with placeholder tags, and Vulnsy fills in the real data — client information, project details, findings, evidence images, and narrative content — every time you export. ## How It Works The export system is built on [Docxtemplater](https://docxtemplater.com/), a templating engine for Word documents. Templates contain placeholder tags written in curly braces (e.g., `{client.name}`, `{report.title}`). When you export a report, Vulnsy replaces every tag with the corresponding data from your report. | Concept | What It Does | |---------|--------------| | **Template tags** | Placeholders in your Word template that get replaced with real data (`{client.name}`, `{#findings}...{/}`) | | **Filters** | Transform a value at the tag: dates (`{report.startDate \| date:"UK"}`), sorting/filtering findings (`{#findings \| where:"severity":"critical"}`), and more | | **Conditionals** | Show or hide a block by comparing a field: `{#report.overallRisk == "critical"} … {/}` | | **Export tag prefixes** | Scope template data to specific report tabs when exporting multi-tab reports | | **Search & Replace** | Replace custom variables (`{{client}}`, `{{scope}}`) across all report content before export | | **Templates** | Word `.docx` files with your formatting, branding, and placeholder tags | ## What Gets Exported When you export a report, the generated DOCX document includes: - **Report metadata** — title, version, status, generation date - **Client information** — company name, contact details, address - **Project details** — engagement name, type, dates, description - **Narrative sections** — executive summary, methodology, scope, and custom sections - **Findings** — all vulnerabilities with severity, description, impact, remediation, and references - **Evidence images** — screenshots and proof-of-concept images embedded directly in the document - **Consultant information** — names and emails of assigned team members ## Export Options Vulnsy gives you three ways to export: | Option | Use Case | |--------|----------| | **All tabs** | Export every tab in the report into a single document | | **Single tab** | Export only one specific tab (e.g., just the "Web Application" section) | | **Custom selection** | Choose which tabs to include in the export | When exporting a single tab, only that tab's findings and narrative content appear in the generated document. Report-level fields like title, client info, and executive summary are always included. ## Pre-Export Checks Before generating the DOCX file, Vulnsy scans your report content for any remaining unreplaced variables — patterns matching `{{...}}` that haven't been resolved through Search & Replace. If any are found, you'll see a warning with the specific variables and where they appear, so you can fix them before delivering the report to your client. ## Next Steps - [Template Tags](/docs/reports/export/template-tags) — complete reference of every tag you can use in your templates - [Export Tag Prefixes](/docs/reports/export/export-tag-prefix) — scope template data to specific tabs in multi-tab reports - [Search & Replace](/docs/reports/export/search-replace) — replace variables and text across your report before export - [Creating Templates](/docs/reports/export/creating-templates) — step-by-step guide to building your own Word templates --- --- title: Search & Replace description: Use preset and custom variables with double-curly-brace syntax to perform bulk text replacement across your Vulnsy report before exporting to DOCX. --- import { Callout } from 'fumadocs-ui/components/callout'; import { Steps, Step } from 'fumadocs-ui/components/steps'; Vulnsy's Search & Replace feature lets you define variables in your report content and replace them with real values before export. This is separate from [template tags](/docs/reports/export/template-tags) — template tags are filled automatically from the database, while variables are placeholders you resolve manually. ## Variables vs. Template Tags These two systems serve different purposes: | Feature | Syntax | Filled By | Used In | |---------|--------|-----------|---------| | **Template tags** | `{tag.name}` (single braces) | Automatically from the database during DOCX export | Word template `.docx` file | | **Variables** | `{{variable_name}}` (double braces) | Manually by you via Search & Replace before export | Report content — narratives, findings, descriptions, and any text field | Template tags live in your Word template and are resolved at export time. Variables live in your report content (the text you write in Vulnsy) and are resolved before export through Search & Replace. Think of template tags as the structure of your document, and variables as shortcuts within your content. Template tags pull data from the database automatically. Variables are text placeholders you fill in yourself. ## Preset Variables Vulnsy provides these built-in variables that you can use throughout your report content: | Variable | Description | |----------|-------------| | `{{client}}` | Client company name | | `{{report_name}}` | Report title | | `{{start_date}}` | Engagement start date | | `{{end_date}}` | Engagement end date | | `{{org}}` | Your organization's name | | `{{scope}}` | Report scope text | These preset variables are available in the Search & Replace UI with pre-filled suggestions based on your report data. ## Custom Variables You can define your own variables using the double-curly-brace syntax: `{{variable_name}}`. Use any name that makes sense for your workflow. **Examples:** | Custom Variable | Use Case | |----------------|----------| | `{{target_url}}` | The primary target URL referenced throughout findings | | `{{testing_environment}}` | "Production", "Staging", etc. | | `{{contact_name}}` | A specific person's name used in multiple places | | `{{app_version}}` | The application version being tested | | `{{network_range}}` | The IP range in scope | To use a custom variable, simply type it anywhere in your report content — in finding descriptions, narrative sections, impact statements, or remediation steps. Then replace it via Search & Replace before export. ## Search & Replace Workflow ### Open the Export Tab Navigate to your report and click the **Export** tab. The Search & Replace section is displayed alongside the export options. ### Enter Variable Values For each variable you want to replace, enter the replacement value. For example: | Find | Replace With | |------|-------------| | `{{client}}` | ACME Corp | | `{{target_url}}` | https://app.acme.com | | `{{start_date}}` | 01/15/2025 | | `{{end_date}}` | 02/15/2025 | ### Preview Replacements Click **Preview** to see exactly where each replacement will occur. Vulnsy scans all report content and shows you: - The number of matches found - Which fields contain matches (e.g., "Finding: SQL Injection — Description", "Tab: Web App — Methodology") - A preview of the text before and after replacement ### Confirm and Replace Review the replacement count and locations. When you're satisfied, click **Replace** to apply the changes across all matching content. ## What Gets Replaced Search & Replace scans and modifies content across your entire report: | Content Area | Examples | |--------------|----------| | **Report fields** | Executive summary, methodology, scope | | **Client/project data** | Client name, project description | | **Tab narratives** | All narrative sections within each tab | | **Finding content** | Title, description, impact, remediation, references | | **Evidence descriptions** | Captions and descriptions attached to evidence items | Replacements are applied directly to your report content in the database. This is not a temporary preview — once you click Replace, the original variable text is overwritten with the replacement value. Make sure your values are correct before confirming. ## Generic Text Search & Replace Search & Replace is not limited to `{{variable}}` patterns. You can search for and replace any text string across your report. This is useful for: - Fixing a misspelled company name across all findings - Updating a URL that changed during the engagement - Replacing placeholder text with final copy - Standardizing terminology (e.g., replacing "webapp" with "web application" everywhere) Simply enter the text to find and the text to replace it with — the same preview and replace workflow applies. ## Unreplaced Variable Detection Before exporting your report, Vulnsy automatically scans all content for any remaining `{{...}}` patterns that haven't been replaced. If any are found, you'll see a warning listing: - The exact variable pattern (e.g., `{{client}}`) - Where it appears (which field, finding, or narrative section) - The number of remaining instances This prevents you from delivering a report to your client with placeholder text still in it. Always check the unreplaced variable warnings before exporting. A stray `{{variable}}` in a client-facing report looks unprofessional and may expose your internal workflow. ## Best Practices - **Use variables for repeated values** — if a client name, URL, or date appears in many places, use a variable instead of typing it everywhere. One replacement updates them all. - **Standardize variable names** across your team — agree on names like `{{client}}`, `{{target_url}}`, and `{{scope}}` so everyone's reports are consistent. - **Preview before replacing** — always check the preview to make sure you're not accidentally replacing text in unexpected places. - **Replace before export** — run Search & Replace as the last step before exporting. This ensures all variables are resolved and the unreplaced variable check comes back clean. ## Next Steps - [Template Tags](/docs/reports/export/template-tags) — understand the automatic template tag system - [Creating Templates](/docs/reports/export/creating-templates) — build Word templates for your exports - [Export Tag Prefixes](/docs/reports/export/export-tag-prefix) — scope data to specific tabs in multi-tab reports --- --- title: Template Tags description: Complete reference for Vulnsy DOCX template tags — fields, filters, conditionals, loops, and the version-agnostic CVSS object for report exports. --- import { Callout } from 'fumadocs-ui/components/callout'; Template tags are placeholders in your Word template that get replaced with real data on export. Vulnsy uses a small, composable tag grammar: a handful of **fields**, a set of **filters** that transform them (`| date`, `| sort`, `| where`, …), and one block syntax (`{#…} … {/}`) that serves as both loop and conditional. You don't memorise hundreds of tags — you compose a few. ## Tag Syntax | Form | Meaning | Example | |------|---------|---------| | `{field}` | Plain-text value | `{report.title}` | | `{~field}` | Rich HTML → Word formatting (bold, lists, links, tables) | `{~description}` | | `{field \| filter:"arg"}` | Transform a value with a filter | `{report.startDate \| date:"UK"}` | | `{#expr} … {/}` | Loop over a collection **or** a conditional block | `{#findings} … {/}` | | `{%image}` | Image (base64 data, inside an evidence loop) | `{%image}` | | `{@field}` | Raw Word XML (advanced/pre-formatted) | `{@captionXml}` | Loop/conditional tags (`{#…}`, `{/}`) and image tags (`{%image}`) must each sit in their **own paragraph** — not inline with other text. **Plain vs. rich.** `{field}` renders a value as plain text; `{~field}` renders an HTML field (description, remediation, narrative sections) with Word formatting. To force an HTML field to plain text — e.g. inside a table cell — pipe it through `| text`: `{description | text}`. Close any block with a bare `{/}` (it closes the nearest open block), or name it explicitly with `{/findings}`. ## Filters Filters transform a value. Write them after a pipe, and chain as many as you like — they apply left to right. ``` {report.startDate | date:"UK"} {#findings | where:"severity":"critical" | sort:"cvss"} … {/} {severity | title} ``` | Filter | Purpose | Example | |--------|---------|---------| | `date:"fmt"` | Format a raw date | `{report.startDate \| date:"US_abbr"}` | | `sort:"order"` | Order a findings collection | `{#findings \| sort:"cvss"}` | | `where:"field":"value"` | Keep only matching items | `{#findings \| where:"severity":"high"}` | | `count` | Number of items in a collection | `{findings \| where:"severity":"critical" \| count}` | | `join:"sep"` | Join a collection into text (default separator `", "`) | `{affectedAssets \| join:", "}` | | `default:"text"` | Fallback when a value is empty | `{report.overallRisk \| default:"Not assessed"}` | | `text` | Strip HTML to plain text | `{description \| text}` | | `upper` / `lower` / `title` | Change letter case | `{severity \| title}` → "Critical" | **Filter arguments:** - `date` formats: `long` (default — "17th March 2025"), `US`, `US_short`, `US_abbr`, `UK`, `UK_abbr`, `month`, `monthYear`, `iso`. - `sort` orders: `severity`, `cvss` (3.1), `cvss3`, `cvss4` (4.0), `auto` (the report's configured order). `count` returns a number, and `0` is falsy — so it doubles as a conditional: `{#findings | where:"severity":"critical" | count}There are critical findings.{/}`. ## Conditionals A `{#…} … {/}` block renders its content only when the expression is truthy. Inside, you can compare real fields — there are no separate boolean tags. ``` {#report.overallRisk == "critical"} This assessment identified critical risk. {/} {#cvss.score >= 7.0}High severity by CVSS.{/} {#severity == "high" || severity == "critical"} Priority remediation required. {/} ``` Permitted operators: `== != > < >= <= && || !`. A bare `{#cvss.temporal} … {/}` is a **presence check** — it renders only when that data exists. Compare against the **stored** value, not the display label. Severity values are `critical`, `high`, `medium`, `low`, `info` (lowercase) — `{#severity == "Informational"}` never matches; use `{#severity == "info"}`. ## Report Fields | Tag | Description | |-----|-------------| | `{report.title}` | Report title | | `{report.version}` | Version number (defaults to "1.0") | | `{report.status}` | Status: `draft`, `review`, or `final` | | `{report.overallRisk}` | Overall risk: `critical`, `high`, `medium`, `low`, `informational`, or `Not Set` | | `{report.sortOrder}` | Finding sort order: `severity`, `cvss`, or `cvss4` | | `{~report.executiveSummary}` | Executive summary (HTML → Word). Plain text: `{report.executiveSummary \| text}` | | `{~report.methodology}` | Methodology (HTML → Word). Plain text: `{report.methodology \| text}` | | `{report.startDate}` | Assessment start date (raw — reformat with `\| date`) | | `{report.endDate}` | Assessment end date (raw — reformat with `\| date`) | Conditional on risk: `{#report.overallRisk == "critical"} … {/}`. Conditional on sort order: `{#report.sortOrder == "cvss"} … {/}`. Assessment dates resolve to the report's override if set, otherwise the parent project's dates. ### Narrative & Scope Sections Every narrative and scope section you write becomes a slug under `report.sections` (lowercased, non-alphanumeric → underscore). Keeping them under `.sections` means a section titled "Findings" can never collide with `report.findings`. A section titled **"Introduction"** → `{~report.sections.introduction}`. A section titled **"Technical Summary"** → `{~report.sections.technical_summary}`. Use `{~report.sections.}` for formatted HTML, or `{report.sections. | text}` for plain text. ## Client Fields | Tag | Description | |-----|-------------| | `{client.name}` | Company name | | `{client.contactName}` | Contact person | | `{client.contactEmail}` | Contact email | | `{client.contactPhone}` | Contact phone | | `{client.address}` | Address | **Custom fields** (key/value pairs you add on the client) are exposed as a loop — add a field in the app and it appears in the report with no template change: ``` {#client.customFields}{label}: {value} {/} ``` ## Project Fields | Tag | Description | |-----|-------------| | `{project.name}` | Project name | | `{project.description}` | Description | | `{project.type}` | Type (`web_app`, `infrastructure`, `mobile`, `cloud`, `api`, `iot`) | | `{project.status}` | Status | | `{project.startDate}` | Start date (raw — reformat with `\| date`) | | `{project.endDate}` | End date (raw — reformat with `\| date`) | `project.*` dates are always the literal project dates. Use `report.startDate` / `report.endDate` when you want the assessment-specific values (which honour a per-report override). **Custom fields:** `{#project.customFields}{label}: {value}{/}`. ## Dates Dates are **raw values**. A bare tag renders the long format; the `date` filter reformats it: | Tag | Output | |-----|--------| | `{report.startDate}` | 17th March 2025 (long, the default) | | `{report.startDate \| date:"US"}` | 03/17/2025 | | `{report.startDate \| date:"UK"}` | 17/03/2025 | | `{report.startDate \| date:"US_abbr"}` | Mar/17/2025 | | `{report.startDate \| date:"month"}` | March | | `{report.startDate \| date:"monthYear"}` | March 2025 | | `{report.startDate \| date:"iso"}` | 2025-03-17 | The same works for `project.startDate`, `project.endDate`, and `metadata.generatedDate`. ## Summary Counts Severity tallies for exec-summary tables. Each is a number. | Tag | Description | |-----|-------------| | `{summary.critical}` | Count of critical findings | | `{summary.high}` | Count of high findings | | `{summary.medium}` | Count of medium findings | | `{summary.low}` | Count of low findings | | `{summary.info}` | Count of informational findings | | `{summary.total}` | Total finding count | These are the same numbers as `{findings | where:"severity":"critical" | count}`, kept as a convenience because nearly every report has a severity table. ## Organization & Metadata | Tag | Description | |-----|-------------| | `{organization.name}` | Organization name | | `{metadata.generatedDate}` | Generation date (raw — reformat with `\| date`) | | `{metadata.generatedBy}` | Name of the user who exported | ## Consultants Loop with `{#consultants} … {/}`: | Tag | Description | |-----|-------------| | `{name}` | Consultant name (falls back to email) | | `{email}` | Email address | | `{jobTitle}` | Job title | | `{separator}` | `, ` after every consultant except the last | Outside the loop, `{consultantNames}` gives all names pre-joined with commas — handy for a single table cell. ## Findings Loop with `{#findings} … {/}`. Each finding exposes: ### Identification & Body | Tag | Description | |-----|-------------| | `{order}` | Sequential number after sorting (1, 2, 3…) | | `{findingId}` | Formatted reference ID, e.g. `REF-C1`, `REF-H2` | | `{title}` | Finding title | | `{severity}` | `critical`, `high`, `medium`, `low`, `info` (e.g. `{severity \| title}`) | | `{status}` | `open`, `in_progress`, `remediated`, `accepted_risk` | | `{~description}` | Description (HTML → Word, with embedded pasted images) | | `{~remediation}` | Remediation (HTML → Word) | | `{~evidenceNarrative}` | Evidence narrative (HTML → Word) | | `{~references}` | References (HTML → Word) | For plain text of any HTML field, pipe through `| text` — e.g. `{description | text}`. ### CVSS CVSS is **one version-agnostic object**. `cvss.*` reflects whatever version the finding is scored with; `{cvss.version}` tells you which (`"3.1"` or `"4.0"`). Write your template against `cvss.*` and it works for both — no version branching. | Tag | Description | |-----|-------------| | `{cvss.version}` | `3.1` or `4.0` | | `{cvss.score}` | Effective overall score (e.g. "7.5") | | `{cvss.vector}` | Full vector string | | `{cvss.severity}` | Severity label ("Critical", "High"…) | | `{cvss.base.score}` / `{cvss.base.severity}` / `{cvss.base.calc}` | Base metrics (`.calc` is a readable breakdown, 3.1) | | `{cvss.temporal.score}` / `.severity` / `.calc` | Temporal metrics (3.1) | | `{cvss.threat.score}` / `.severity` | Threat metrics (4.0) | | `{cvss.environmental.score}` / `.severity` / `.calc` | Environmental metrics | **Presence conditionals** (each renders only when that data exists — `0`/absent is falsy): ``` {#cvss.present}CVSS v{cvss.version}: {cvss.score} ({cvss.severity}){/} {#cvss.hasTemporal}Temporal: {cvss.temporal.score}{/} {#cvss.hasThreat}Threat: {cvss.threat.score}{/} {#cvss.hasEnvironmental}Environmental: {cvss.environmental.score}{/} ``` **Showing both versions side by side** — the explicit `cvss.v3_1` and `cvss.v4_0` objects (each present only if the finding carries that version): ``` {#cvss.v3_1}CVSS 3.1: {cvss.v3_1.score} — {cvss.v3_1.vector}{/} {#cvss.v4_0}CVSS 4.0: {cvss.v4_0.score} — {cvss.v4_0.vector}{/} ``` Each has the same nested shape (`.score`, `.vector`, `.severity`, `.base.*`, etc.). ### Evidence (nested loop) `{#evidence} … {/}`: | Tag | Description | |-----|-------------| | `{fileName}` | File name | | `{description}` | Description / caption | | `{%image}` | The image (base64 data) | | `{figureNumber}` | Sequential figure number across the document | | `{caption}` | "Figure N - description" | | `{@captionXml}` | Pre-formatted Word caption XML (Caption style + SEQ field) | ### Affected Assets (nested loop) `{#affectedAssets} … {/}`: | Tag | Description | |-----|-------------| | `{type}` | `url`, `ip`, `hostname`, `network`, `other` | | `{value}` | The asset value | | `{description}` | Asset description | For a single cell, join them instead of looping: `{affectedAssets | join:", "}` (or `{affectedAssets | join:"\n"}` for one per line). ### Custom Fields (nested loop) Per-finding key/value fields: `{#customFields}{title}: {content}{/}`. ### Ordering & Filtering Findings Instead of separate pre-sorted arrays, apply `sort` and `where` to the findings collection: ``` {#findings | sort:"cvss"} … {/} ← highest CVSS first {#findings | where:"severity":"critical"} … {/} ← critical only {#findings | where:"severity":"high" | sort:"cvss"} … {/} ← high, CVSS-ordered ``` Count matches (also works as a conditional): `{findings | where:"severity":"critical" | count}`. ## Tabs A report can have multiple tabs (e.g. "Web Application", "Infrastructure"). Loop every tab with `{#tabs} … {/}`. Inside the loop: | Tag | Description | |-----|-------------| | `{name}` | Tab name | | `{exportTagPrefix}` | The tab's prefix, e.g. "appsec" | | `{overallRisk}` | Tab's overall risk — conditional: `{#overallRisk == "critical"} … {/}` | | `{sortOrder}` | Tab's finding sort order | | `{findingCount}` | Number of findings in this tab (use as a conditional to skip empty tabs) | | `{~sections.}` | This tab's narrative sections by slug | | `{#findings} … {/}` | Findings scoped to this tab (supports `\| sort` / `\| where`) | ``` {#tabs} {name} — {findingCount} findings {#findings | sort:"severity"} {findingId}. {title} ({severity | title}) {~description} {/} {/tabs} ``` ### Prefix-Scoped Tags (no loop) When a tab has a custom `exportTagPrefix` (e.g. `appsec`), its data is also reachable at the top level under that prefix — useful for fixed-layout templates that don't loop tabs: | Tag | Description | |-----|-------------| | `{#appsec.findings} … {/}` | That tab's findings (supports `\| sort` / `\| where`) | | `{appsec.findingCount}` | That tab's finding count | | `{appsec.sortOrder}` | That tab's sort order | | `{appsec.overallRisk}` | That tab's overall risk | | `{~appsec.sections.}` | That tab's narrative section by slug | Replace `appsec` with any custom prefix. When the prefix is `report` (the default), these live under `report.*`. ## Template Patterns ### Simple Report ``` {report.title} Client: {client.name} Date: {report.startDate | date:"UK"} — {report.endDate | date:"UK"} {~report.executiveSummary} {#findings | sort:"severity"} {findingId} - {title} ({severity | title}) CVSS: {cvss.score} ({cvss.severity}) {~description} {~remediation} {#evidence} {%image} {@captionXml} {/evidence} {/findings} ``` ### Severity Sections (via `where`) ``` {#tabs} {#findingCount} {name} Technical Findings {#findings | where:"severity":"critical"} {title} — {cvss.score} {~description} {~remediation} {/} {#findings | where:"severity":"high"} {title} — {cvss.score} {~description} {/} {/findingCount} {/tabs} ``` Wrap tab content in `{#findingCount} … {/}` to skip tabs with no findings, and put page breaks **inside** the severity blocks so they're skipped when empty. ### Consultants Table | Consultant | Email | Role | |---|---|---| | `{#consultants}{name}` | `{email}` | `{jobTitle}{/consultants}` | Or a single string: `{consultantNames}`. ## Moving From the Old Tags If you have a template written for Vulnsy's earlier tag set, here's what changed. The old tags are no longer provided — update to the replacements below. | Old tag | Replacement | |---------|-------------| | `{report.executiveSummary_plain}`, any `{field_plain}` | `{report.executiveSummary \| text}`, `{field \| text}` | | `{report.introduction}`, `{~report.introduction}` | `{~report.sections.introduction}` | | `{project.startDateUK}`, `{…startMonthYear}`, all date variants | `{project.startDate \| date:"UK"}`, `{… \| date:"monthYear"}` | | `{cvssScore}`, `{cvssVector}`, `{cvssBaseScore}`, `{cvssBaseCalc}` | `{cvss.score}`, `{cvss.vector}`, `{cvss.base.score}`, `{cvss.base.calc}` | | `{cvss3Score}` / `{cvss4Score}` | `{cvss.v3_1.score}` / `{cvss.v4_0.score}` | | `{#hasCvss}`, `{#hasTemporalScore}` | `{#cvss.present}`, `{#cvss.hasTemporal}` | | `{#findingsBySeverity}`, `{#findingsByCvss}` | `{#findings \| sort:"severity"}`, `{#findings \| sort:"cvss"}` | | `{#criticalFindings}`, `{#highFindings}`, … | `{#findings \| where:"severity":"critical"}`, `{… "high"}`, … | | `{#report.isSortedByCvss}`, tab `{#isCritical}` | `{#report.sortOrder == "cvss"}`, `{#overallRisk == "critical"}` | | `{affectedAssets_text}` | `{affectedAssets \| join:", "}` | | `{#allTabs}`, `{#appsec_tabs}` | `{#tabs}` | | `{#appsec.criticalFindings}` | `{#appsec.findings \| where:"severity":"critical"}` | --- --- title: Reports Overview description: Reports are the main deliverable in Vulnsy — professional pentest reports generated from your engagement data, with narrative, findings, and exports. --- import { Callout } from 'fumadocs-ui/components/callout'; A report is the primary deliverable you produce in Vulnsy. It is a structured pentest report linked to a project, built from your engagement data, and exported as a professional DOCX document for your client. ## What Is a Report? Each report belongs to a project and contains everything needed to produce a client-ready document: | Component | Purpose | |-----------|---------| | **Tabs** | Top-level sections representing different testing areas (e.g., "Web Application", "Infrastructure") | | **Narrative sections** | Free-form content blocks within each tab — Scope, Methodology, Executive Summary, and custom sections | | **Findings** | Vulnerabilities assigned to specific tabs, imported from your library or created inline | | **Export configuration** | Template selection, tag prefixes, and sort order for generating DOCX output | ## Report Fields Every report has the following top-level fields: | Field | Description | |-------|-------------| | **Title** | The name of the report (e.g., "Q1 2025 External Penetration Test") | | **Version** | A version identifier for tracking revisions | | **Status** | Current state — `Draft`, `Review`, or `Final` | | **Executive Summary** | High-level overview of the engagement and results | | **Methodology** | Description of the testing approach used | | **Scope** | What was tested and any boundaries or exclusions | Report fields like executive summary, methodology, and scope are also available as template tags during DOCX export, so they flow directly into your generated documents. ## How Reports Fit into Vulnsy Reports sit within the project hierarchy: - A **Client** has one or more **Projects** - Each **Project** has one or more **Reports** - Each **Report** contains one or more **Tabs** - Each **Tab** contains **Narrative sections** and **Findings** This structure lets you produce multiple reports per engagement — for example, a draft report and a retest report — all under the same project. ## Report Workflow 1. **Create a report** inside a project 2. **Add tabs** for each testing area you need to cover 3. **Write narrative sections** — scope, methodology, executive summary, and any custom sections 4. **Add findings** to each tab from your library or create them inline 5. **Configure export settings** — choose a template, set sort order, and assign tag prefixes 6. **Export to DOCX** — generate the final document ## Next Steps - [Report Tabs](/docs/reports/tabs) — understand how tabs organize your report into testing areas - [Narrative Sections](/docs/reports/narrative) — write and manage the content blocks within each tab - [Report Findings](/docs/reports/report-findings) — add and manage findings in your report - [Exporting Reports](/docs/reports/export) — configure templates and generate DOCX output --- --- title: Narrative Sections description: Narrative sections are the free-form content blocks within each report tab — scope, methodology, executive summary, and custom sections. --- import { Callout } from 'fumadocs-ui/components/callout'; Narrative sections are the written content blocks inside each report tab. They provide the context around your findings — explaining what was tested, how testing was performed, and what the overall results mean. ## Where Written Content Lives A report's written content is split between report-level fields and per-tab sections: | Content | Level | Purpose | |---------|-------|---------| | **Executive Summary** | Report | High-level overview of results for non-technical stakeholders | | **Methodology** | Report | The testing approach, tools, and standards followed (e.g., OWASP, PTES) | | **Additional sections** (e.g. Scope) | Report | Define what was tested, exclusions, limitations — add as many as you need | | **Narrative sections** | Tab | Free-form content specific to one testing area | ## Custom Sections You can add narrative sections to any tab to cover additional topics. Common examples include: - Testing Environment - Assumptions and Limitations - Positive Observations - Remediation Priorities - Compliance Mapping To add a custom section, use the **Add Section** button within a tab. Each custom section has a title and a content area. ## Editing Content Narrative sections use a TipTap rich text editor. The editor supports: | Formatting | Description | |------------|-------------| | **Headings** | H1 through H6 for structuring content | | **Bold / Italic** | Emphasis and strong emphasis | | **Ordered lists** | Numbered step-by-step lists | | **Unordered lists** | Bullet point lists | | **Tables** | Structured data within narrative content | | **Links** | Hyperlinks to external resources | Content is stored as HTML internally and rendered in the exported DOCX according to your template's styling. The rich text editor provides a visual editing experience. You do not need to write HTML directly — the editor handles formatting through its toolbar. ## Search and Replace Narrative sections are included in Vulnsy's **search and replace** system. This lets you use placeholder variables throughout your narrative content and replace them in bulk before export. For example, you might write: ``` Testing was performed between {{start_date}} and {{end_date}} against {{target_url}}. ``` Then use search and replace to substitute the actual values across all narrative sections in the report at once. Search and replace operates across all narrative sections in all tabs of the report. Double-check your replacements before exporting to make sure the correct values were applied everywhere. ## How Narratives Appear in Exports When you export a report to DOCX, narrative content is injected into the template using tags. Use the `~` prefix so the rich text renders with Word formatting: | Content | Template Tag | |---------|-------------| | Executive Summary | `{~report.executiveSummary}` | | Methodology | `{~report.methodology}` | | Additional sections (e.g. a section titled "Scope") | `{~report.sections.scope}` | | Tab narrative sections | `{~sections.}` inside a `{#tabs}` loop, or `{~web.sections.}` using the tab's prefix | Section slugs come from the section title, lowercased with spaces as underscores — a section titled "Testing Environment" becomes `{~report.sections.testing_environment}`. ## Next Steps - [Report Tabs](/docs/reports/tabs) — understand how tabs organize narrative sections - [Report Findings](/docs/reports/report-findings) — add findings alongside your narratives - [Template Tags Reference](/docs/reports/export/template-tags) — full list of tags available for narratives --- --- title: Report Findings description: Add findings to report tabs from your library or create them inline, with custom ordering, evidence, and report-specific overrides. --- import { Callout } from 'fumadocs-ui/components/callout'; Findings are the vulnerabilities documented in your report. Each finding is assigned to a specific report tab, where it receives a reference ID, can be reordered, and can have report-specific content overrides. ## Adding Findings to a Report There are two ways to add findings to a report tab: - **Import from library** — select existing findings from your organization's finding library. This pulls in the title, description, severity, CVSS score, remediation, and all other fields. - **Create inline** — create a new finding directly within the report for one-off vulnerabilities specific to this engagement. Importing from the library is the recommended approach. It keeps your findings consistent across engagements and builds a reusable knowledge base over time. ## Finding Properties in a Report Each finding within a report tab has the following properties: | Property | Description | |----------|-------------| | **Order number** | Controls the position of the finding in the report | | **Reference ID** | Generated from the tab's Finding ID Prefix and severity (e.g., REF-C1) | | **Content overrides** | Report-specific edits to the finding that do not affect the library version | | **Evidence** | Screenshots and supporting material attached to this finding in this report | ## Reference IDs Finding reference IDs are generated automatically based on: 1. The tab's **Finding ID Prefix** (default: `REF`) 2. The finding's **severity level** (C = Critical, H = High, M = Medium, L = Low, I = Informational) 3. A **sequential number** within that severity group For example, a tab with prefix `REF` containing three critical findings and two high findings would produce: | Finding | Severity | Reference ID | |---------|----------|--------------| | SQL Injection | Critical | REF-C1 | | RCE via Deserialization | Critical | REF-C2 | | Authentication Bypass | Critical | REF-C3 | | Stored XSS | High | REF-H1 | | IDOR | High | REF-H2 | ## Content Overrides When you import a finding from the library, the report receives a copy of the finding's content. You can edit this copy to tailor it for the specific engagement — for example, adding client-specific details to the description or adjusting the remediation steps. These edits are **report-specific overrides**. They do not modify the original finding in your library. Content overrides are one-way. Changes made in the report do not propagate back to the library, and subsequent updates to the library finding do not automatically update existing report copies. ## Ordering and Sorting Findings within a tab can be organized in two ways: - **Drag-and-drop** — manually reorder findings by dragging them to the desired position - **Sort by severity or CVSS** — automatically sort findings using the tab's configured **Findings Sort Order** (`severity`, `cvss` for 3.1, or `cvss4` for 4.0) The sort order setting on the tab determines the default ordering when the report is exported. ## Evidence Each finding in a report can have evidence attached — typically screenshots demonstrating the vulnerability. Evidence is specific to the report instance, so the same library finding can have different evidence in different reports. ## Reusing Findings Across Reports The same library finding can be imported into multiple reports without conflict. Each report maintains its own independent copy with its own: - Reference ID - Order number - Content overrides - Evidence This means you can use a standard "SQL Injection" finding across dozens of engagements, customizing the details for each client without affecting other reports. ## Next Steps - [Findings Library](/docs/findings) — manage your reusable finding templates - [Report Tabs](/docs/reports/tabs) — understand how findings are organized within tabs - [Exporting Reports](/docs/reports/export) — see how findings appear in the exported DOCX --- --- title: Report Tabs description: Tabs are the top-level sections of a Vulnsy report, each representing a distinct testing area with its own findings, narratives, and export settings. --- import { Callout } from 'fumadocs-ui/components/callout'; Tabs are the top-level structural divisions of a report. Each tab represents a separate testing area — for example, "Web Application Testing", "Infrastructure Testing", or "Mobile App Testing" — and contains its own narrative sections and findings. ## Why Tabs? Many pentest engagements cover more than one testing area. Instead of creating separate reports for each area, tabs let you organize everything inside a single report. Each tab can be exported independently or together, depending on your template configuration. ## Tab Fields Each tab has the following configurable fields: | Field | Description | |-------|-------------| | **Name** | The display name shown in the report (e.g., "Web Application Testing") | | **Export Tag Prefix** | A short prefix used to scope template tags for multi-tab exports (e.g., `web`, `infra`) | | **Finding ID Prefix** | The prefix for finding reference numbers — defaults to `REF` (e.g., REF-C1, REF-H2) | | **Findings Sort Order** | How findings are ordered in the export — `severity`, `cvss` (3.1), or `cvss4` (4.0) | | **Report Style** | The visual template applied when exporting this tab | | **Overall Risk** | The risk rating for this testing area — Critical, High, Medium, Low, or Informational | ## How Export Tag Prefixes Work When a report has multiple tabs, each tab's template tags are scoped using its export tag prefix. This lets a single DOCX template pull data from different tabs into different sections of the document. For example, if you have two tabs: | Tab | Export Tag Prefix | |-----|-------------------| | Web Application Testing | `web` | | Infrastructure Testing | `infra` | Then in your template, `{~web.sections.scope}` pulls the scope section from the web tab, and `{~infra.sections.scope}` pulls it from the infrastructure tab. The same works for findings: `{#web.findings}…{/}` loops only the web tab's findings. See [Export Tag Prefixes](/docs/reports/export/export-tag-prefix) for full details on how multi-tab template tags work. ## Finding Reference IDs Each finding within a tab is assigned a reference ID using the tab's **Finding ID Prefix** combined with the finding's severity letter and position. The default prefix is `REF`. For example, with prefix `REF`: | Finding | Severity | Reference ID | |---------|----------|--------------| | SQL Injection | Critical | REF-C1 | | Stored XSS | High | REF-H1 | | Missing Headers | Medium | REF-M1 | ## Tab Contents Each tab contains two types of content: - **Narrative sections** — free-form content blocks like Scope, Methodology, and Executive Summary. See [Narrative Sections](/docs/reports/narrative). - **Findings** — vulnerabilities assigned to this tab. See [Report Findings](/docs/reports/report-findings). ## Working with Multiple Tabs You can add as many tabs to a report as your engagement requires. Common multi-tab configurations include: | Engagement Type | Typical Tabs | |-----------------|-------------| | Full-scope pentest | Web Application, Infrastructure, Wireless | | Application assessment | External Web App, Internal API, Mobile App | | Retest engagement | Original Assessment, Retest Results | Each tab maintains its own findings and narrative sections independently. Reordering or editing findings in one tab does not affect other tabs. ## Next Steps - [Narrative Sections](/docs/reports/narrative) — write content within each tab - [Report Findings](/docs/reports/report-findings) — assign findings to tabs - [Export Tag Prefixes](/docs/reports/export/export-tag-prefix) — configure multi-tab template tags --- --- title: Common Errors description: Solutions for common platform errors in Vulnsy -- login issues, permission errors, file upload failures, and more. --- import { Callout } from 'fumadocs-ui/components/callout'; This page covers common errors you may encounter while using Vulnsy and how to resolve them. ## "No template selected" **When:** Exporting a report. **Cause:** No DOCX template has been assigned to the report you are trying to export. **Fix:** 1. Open the report and go to its **Export** tab 2. Select a template from the **Report Template** dropdown 3. Try the export again You can set a default template for all new reports at **Admin > Templates**. This prevents this error for future reports. ## "No findings in report" **When:** Exporting a report. **Cause:** The report tab has no findings assigned to it. **Fix:** 1. Open the report tab 2. Add at least one finding -- either from your library or create one inline 3. Try the export again ## Login Issues **Symptoms:** Cannot log in, credentials rejected, session expired. **Fix:** 1. Make sure you are logging in at your organization's own address (e.g. `yourteam.vulnsy.com`) — credentials are workspace-specific 2. Verify your email and password are correct 3. Clear your browser cache and cookies, or try a private/incognito window 4. Use the **Forgot Password** link to reset your password if needed If you still cannot log in, contact your organization admin — they can confirm your account exists and is active in the workspace. ## Permission Denied **Symptoms:** "You do not have permission" message, feature is greyed out or inaccessible, 403 error. **Cause:** Your user role does not have the required permissions for the action you are attempting. **Fix:** 1. Check your current role in your profile settings 2. Contact your organization administrator to review your role and permissions 3. See [Permissions](/docs/admin/permissions) for details on what each role can access ## File Upload Failures **Symptoms:** File upload hangs, fails, or shows an error message. **Cause:** The file exceeds size limits, or S3 storage is not configured correctly. **Fix:** 1. Check the file size -- ensure it is within your plan's upload limits 2. Try a smaller file to confirm uploads work in general 3. If no uploads work, ask your admin to check the S3 configuration status in **Admin > Organization Settings** 4. Verify your organization has not exceeded its storage quota ## Still Need Help? If you cannot resolve your issue using the steps above: - Email support at [support@vulnsy.com](mailto:support@vulnsy.com) - Include your organization name, the steps to reproduce the issue, and any error messages Enterprise plan customers have access to a dedicated support channel with faster response times. --- --- title: Export Issues description: Troubleshoot problems with DOCX report exports in Vulnsy -- tags not replaced, images missing, loops broken, and more. --- import { Callout } from 'fumadocs-ui/components/callout'; Report export issues are almost always caused by template formatting problems in your DOCX file. This page covers the most common export issues and how to fix them. ## Tags Not Replaced **Symptom:** The exported document still shows raw tags like `{report.title}` instead of actual values. **Cause:** Word splits tags across multiple XML runs when you copy/paste or edit them after typing. The tag looks correct visually, but the underlying XML is fragmented. **Fix:** 1. Open your template in Word 2. Delete the broken tag completely 3. Retype the tag in one continuous motion -- do not pause, backspace, or edit mid-tag 4. Save the template and re-upload to Vulnsy Tags are case-sensitive. `{report.Title}` and `{report.title}` are different tags. Check the exact spelling against the [Template Tags reference](/docs/reports/export/template-tags), or download the per-report **Tag Reference** from the report's Export tab to see every available tag with its live value. ## Images Not Appearing **Symptom:** Image placeholders are blank or missing in the exported document. **Cause:** The `{%image}` tag is not in its own paragraph, or the finding has no image data in the evidence field. **Fix:** 1. Ensure the `{%image}` tag is on its own line in the template -- it must be the only content in that paragraph 2. Verify that the finding has evidence with image data attached 3. Check that the image data exists in the database (not just a broken reference) ## Loops Not Working **Symptom:** Loop content is missing, duplicated incorrectly, or shows raw loop tags. **Cause:** The opening `{#loop}` and closing `{/loop}` tags are not in separate paragraphs, or the array name does not match. **Fix:** 1. Place `{#loop}` on its own line (separate paragraph) 2. Place `{/loop}` on its own line (separate paragraph) 3. Ensure the content between the tags is in its own paragraph(s) 4. Verify the array name matches exactly: | Loop | Array Name | |------|-----------| | Findings | `findings` | | Evidence | `evidence` | | Consultants | `consultants` | | Tabs | `tabs` | ``` {#findings} Title: {title} Severity: {severity} {/findings} ``` ## Empty Values **Symptom:** Tags are replaced but with blank/empty content. **Cause:** The field has no data in the database, or the report is linked to the wrong project or client. **Fix:** 1. Open the report in Vulnsy and check that the field has content 2. Verify the report is linked to the correct project and client 3. For client/project fields, check that the parent record has the data filled in ## Unreplaced Variables Warning **Symptom:** Vulnsy warns about unreplaced `{{variable}}` placeholders before export, or they appear in the exported document. **Cause:** `{{variable}}` placeholders are content variables you write in your report text (e.g. `{{target_url}}`). They are meant to be resolved with Vulnsy's Search & Replace before export — the pre-export scan warns you about any leftovers so they never reach a client. **Fix:** 1. Open the report's **Export** tab 2. Use the **Search & Replace** section to fill in each variable's value and apply the replacements 3. Export again — the warning disappears once no `{{...}}` patterns remain Vulnsy template tags use single braces (`{report.title}`) and live in your Word template. Double-brace `{{variables}}` live in your report content and are resolved in-app — see [Search & Replace](/docs/reports/export/search-replace). ## Export Fails Entirely **Symptom:** The export process errors out and no document is produced. **Fix:** 1. Check that a template is assigned to the report tab 2. Ensure the template file is a valid `.docx` file (not `.doc` or renamed) 3. Try re-uploading the template at **Admin > Templates** 4. Check server logs for specific error messages if you have admin access If the export continues to fail after trying the above steps, contact support at [support@vulnsy.com](mailto:support@vulnsy.com) with the report ID and any error messages you see. --- --- title: Troubleshooting description: Common issues in Vulnsy and how to resolve them — login problems, export errors, missing data, and platform-specific quirks with step-by-step fixes. --- import { Callout } from 'fumadocs-ui/components/callout'; This section covers the most common issues you may encounter when using Vulnsy, along with their solutions. ## Categories | Category | What It Covers | |----------|---------------| | **Export Issues** | Problems with DOCX report generation -- tags not replaced, images missing, loops not working | | **Common Errors** | Platform errors -- login issues, permission denied, file upload failures | ## Quick Fixes Before diving into specific issues, try these general steps: 1. **Refresh the page** -- clears stale state 2. **Clear browser cache** -- resolves issues caused by cached assets 3. **Check your permissions** -- ensure your role has access to the feature you are using 4. **Try a different browser** -- rules out browser-specific issues If you cannot resolve an issue using this guide, contact support at [support@vulnsy.com](mailto:support@vulnsy.com). ## Next Steps - [Export Issues](/docs/troubleshooting/export-issues) -- resolve report export problems - [Common Errors](/docs/troubleshooting/common-errors) -- fix platform and access errors