Data Concepts & Access

Data Concepts Overview

The following diagram illustrates the data concepts of AttackForge:

Access Control Overview

Access Controls in AttackForge can be configured for the following:

• Custom Field-Level Access Control

• Portfolios

• Streams

• Project Requests

• Projects (which controls access to Vulnerabilities)

• Asset Libraries

• Writeup Libraries

• Report Templates

• Groups

• Test Suites

• Flows

• Actions

• Workspace

• Reports

• Pages

• Project Test Cases

• Retests

• Attack Chains

• Self-Service RESTful APIs - access per API Endpoint

• Self-Service Events APIs - access per API Event

• AI Model Context Protocol (MCP) - access per Tool

Onboarding External Testing Vendors

If you're an internal/enterprise security team - there are many reasons you may consider to bring your external vendors (consultants / MSSPs) into your AttackForge environment:

Direct benefits	Rationale
No import pipeline to maintain	No building custom scripts per vendor to import their findings and evidence. No format drift when they change their export. No rejected rows to chase. No reconciliation QA against the source report during the reporting crunch.
Findings land as they're discovered	Critical findings surface immediately, so remediation runs in parallel with testing rather than after it. For anything approaching a Continuous Testing and Exposure Management (CTEM) model this is the whole point – the engagement stops being a report delivery and becomes a live feed.
Methodology and coverage are captured, not just outcomes	Test cases get worked through and annotated in place, so you end up with evidence of what was tested and passed, not only what failed. There’s also standardised testing coverage which is aligned with your organizations risk appetite. That's the material that answers audit questions, justifies scope decisions, and lets you compare one vendor's thoroughness against another's or against your internal team on the same asset class.
Better prioritization, clearer reporting, faster response, less duplicates	Findings link to Writeups, severities and CVSS vectors follow your scheme, and affected assets map to the asset records. Deduplication works, lineage across engagements holds, and Portfolio-level trending is built on clean data rather than reconciled data. Retests link back to the original finding instead of appearing as new entries.
Automation fires at the right time, in the right order	Flows, Actions, Jira sync and notifications trigger per finding as it's raised, so tickets reach owners while the tester is still on site. SLA clocks start on genuine discovery dates, which means your time-to-remediate reporting is actually measuring what it claims to.
Evidence lands with the finding	Screenshots, request/response pairs, PoC files and formatted reproduction steps go in at the moment of writing, when the tester has all the context. AttackForge ReportGen then produces a usable report straight from that data – no separate authoring pass, no reliance on a vendor PDF as the real artefact.
The retest loop closes inside the platform	Request a retest, the tester who found it verifies it, status and evidence are recorded against the same record. No email round trips, no re-importing verification results, and the full remediation history stays on the finding.
Direct communication with the person who found it	Comments and questions sit on the finding rather than in someone's inbox, so a developer's "I don't think this is exploitable in our config" gets answered by the tester, on the record, permanently – visible to the auditor.
Per-tester attribution and a real audit trail	Every action is timestamped against an individual. That's better for accountability, better for demonstrating independence, and useful when you need to know who to ask about a two-year-old finding.
Vendor consistency at scale	If you're using several consultancies or MSSPs, direct entry forces a common structure on all of them. Their output becomes comparable – coverage, finding quality, turnaround – which makes vendor performance measurable rather than anecdotal.
Data ownership and continuity	The findings are yours from the moment they're written, independent of whether you renew with that vendor or whether their own platform still holds the history.

Checklist for onboarding Vendors

• Confirm that external Vendor users will be logging in with Local accounts, and give them the Consultant role. Otherwise, if logging in via SSO – check the SSO Role Mapping to ensure they will receive the Consultant role.

• Create a new Group for each Vendor. Configure your point of contact at the Vendor as a Group Membership Administrator so they can on-board and off-board their team as needed. This eliminates the burden for you having to manage their teams access to AttackForge.

• Review all of your existing access controls – remove any assignments to the Consultant role – and replace with group-based access control for your Internal Pentester group. This ensures the internal pentesters maintain their access and can be differentiated from external vendors. If access controls are applied effectively – vendors will not be able to see each other or know of each other’s existence within AttackForge.

• If your intention is to allow your Vendors to be able to create their own Writeups – create a new Writeups library for each Vendor and give them Edit access to their own library.

• Give each Vendor Group View access to Writeups libraries you would like to share with them. This will allow them to reference those writeups but not change them when creating vulnerabilities.

• When creating Projects – link the Vendor Group to the project. This will ensure they can inherit access to the project they are working on. Alternatively, configure the Vendor point of contact as a Project Membership Administrator so they can selectively add their testers to the project as needed.

• Create a Consultant test account which is representative of an external Vendor account. Log in to confirm that this account is restricted to your requirements. This is an important step to validate your configuration is applied effectively, and to provide assurance that you are ready to start onboarding your vendors.

When it comes to whether external vendors should have access to Asset Libraries - this is only required for Importing Vulnerabilities. The external vendors will be able to see the asset data on the Project Scope regardless.

If you do not need your external vendors importing vulnerabilities - we recommend not giving them access to any asset libraries.

If you do need your external vendors importing vulnerabilities - we recommend creating a dedicated asset library for them, and giving them Edit access to their own library. Any assets they create will be stored in their library only. You can then link or move those assets into your other asset libraries if you wish to do so.