> For the complete documentation index, see [llms.txt](https://docs.devsolve.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devsolve.app/start-here/how-devsolve-works.md).

# How DevSolve Works

The platform follows a structured workflow to ensure that vulnerability reports are reviewed fairly and efficiently.

### 1. Company Creates a Security Program

A company creates a security program on DevSolve and defines important information such as:

* Program type
* Security scope
* Rules and guidelines
* Vulnerability exclusions
* Program visibility
* Bounty or reward information

Once the program is published, ethical hackers can view and participate in the program.

### 2. Hacker Finds a Vulnerability

An ethical hacker browses available programs and reviews the program's scope and rules.

After discovering a potential security vulnerability, the hacker prepares a detailed report with information such as:

* Vulnerability title
* Description
* Steps to reproduce
* Proof of Concept (PoC)
* Supporting evidence
* Claimed severity

### 3. Hacker Submits the Report

The hacker submits the vulnerability report through DevSolve.

The report is then sent privately to the company for review. The hacker can track the report status through the platform.

### 4. Company Reviews the Report

The company reviews the submitted report and verifies whether the vulnerability is valid.

The company can:

* Accept the report
* Reject the report
* Request additional information
* Assess the vulnerability severity

### 5. Severity Agreement

DevSolve uses a structured severity process.

There are three severity values:

1. **Hacker Claimed Severity** – The severity selected by the hacker.
2. **Company Assessed Severity** – The severity assigned by the company.
3. **Final Severity** – The agreed severity used as the final result.

If both the hacker and company agree on the severity, the final severity is automatically confirmed.

If they disagree, the report can be reviewed by a platform administrator for dispute resolution.

### 6. Company Fixes the Vulnerability

After the vulnerability is accepted, the company works to fix the security issue.

Once the fix is completed, the company can request a retest.

### 7. Hacker Performs a Retest

The hacker tests the system again to verify whether the vulnerability has been successfully fixed.

The hacker can then:

* Confirm that the vulnerability is resolved
* Report that the issue still exists

### 8. Report is Resolved

When the vulnerability is successfully fixed and verified, the report is marked as resolved.

The hacker may receive:

* Reputation points
* Recognition
* Badges
* Leaderboard progress

> **Note:** Any financial reward or bounty payment is handled outside the DevSolve platform.

### DevSolve Workflow

```
Company Creates Program
        ↓
Hacker Browses Program
        ↓
Hacker Finds Vulnerability
        ↓
Hacker Submits Report
        ↓
Company Reviews Report
        ↓
Is the Report Valid?
     ↙         ↘
   Yes          No
    ↓            ↓
Assess Severity  Reject Report
    ↓
Do Both Agree?
   ↙       ↘
 Yes       No
  ↓         ↓
Confirm     Admin Resolves
Severity    Dispute
  ↓           ↓
  └─────→ Final Severity
              ↓
        Company Fixes Issue
              ↓
        Request Retest
              ↓
        Hacker Retests
              ↓
           Resolved
```

### Summary

DevSolve provides a structured workflow that helps companies and ethical hackers collaborate throughout the vulnerability management process. From creating a security program to submitting reports, reviewing vulnerabilities, resolving severity disagreements, and retesting fixes, DevSolve helps make the process organized, transparent, and collaborative.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.devsolve.app/start-here/how-devsolve-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.