To understand the Security Program structure, refer to the diagram below:
The Organization is the top-most layer of initial customer data and ongoing resource management. Resources are allocated from the Organization to one or more Security Programs by means of delegation. For example, the Organization allocates funds to Security Programs (reward pools) and used to pay hackers. Users are created at the Organization and given roles specific to the Security Programs to which they’re assigned.
The Security Program is the container of target scope, submissions, and settings enabled by one or more Engagements of the same or differing types (e.g. Vulnerability Disclosure, Bug Bounty, Pen Test). For further details about an Engagement see the Engagement Overview documentation. The definition and use of a Security Program is meant to align to your organization’s structure and preferences (e.g. business units, security teams, app / tech domains).
A Security Program defines the boundary of access and permission. Customer team members assigned to a Security Program will have access to all Engagements within that Security Program. Therefore, it’s important that your delegation of scope across multiple Security Programs contemplates which team members should have access to that scope and its submissions.
Submissions are made to a Security Program via an Engagement. Team members can consume a rollup of reporting and insights across some or all Engagements in a Security Program based on their needs.
Bugcrowd’s outgoing integrations that support customer workflows (e.g. Jira, ServiceNow) are configured at the Security Program level and made available to all Engagements in that Security Program. Incoming submission integrations (e.g. embedded submission form, email intake) are also configured at the Security Program and may be assigned to an Engagement.
