A Code of Conduct is the behavioural standard that tells security researchers how to act while testing. In bug bounty and vulnerability disclosure programmes, it sets expectations for professionalism, safe handling of data, responsible reporting, and avoiding disruption or damage.
Expanded Definition
A Code of Conduct in security research is the behavioural agreement that governs how participants interact with systems, data, and programme owners during authorised testing. It is broader than a simple etiquette statement: it sets boundaries for lawful activity, disclosure discipline, evidence handling, communications, and acceptable test impact. In vulnerability disclosure programmes and bug bounty settings, a strong code of conduct helps distinguish coordinated security research from reckless probing, especially when testing touches production assets, customer data, or third-party services.
Usage in the industry is still evolving because some programmes treat the code as a policy appendix, while others make it a binding condition of participation. In practice, it often complements legal terms, scope definitions, and safe harbour language rather than replacing them. A mature code should align with broader governance expectations such as the NIST Cybersecurity Framework 2.0, especially where disciplined reporting and risk reduction are the goal.
The most common misapplication is treating the code as a symbolic document, which occurs when a programme publishes rules but does not enforce them during triage, escalation, or researcher onboarding.
Examples and Use Cases
Implementing a Code of Conduct rigorously often introduces reporting discipline and response overhead, requiring organisations to weigh researcher flexibility against the need for predictable, low-risk engagement.
- A bug bounty programme requires researchers to stop testing once they encounter sensitive personal data, then report the issue without copying or storing unnecessary evidence.
- A vulnerability disclosure programme states that social engineering, phishing, and physical intrusion are out of bounds even if the target is in scope.
- A red team engagement includes rules for safe rollback, so destructive proof-of-concept activity must be approved before any live testing begins.
- A programme uses the code of conduct to define communication channels, response timelines, and escalation steps when a researcher discovers a critical exploit chain.
- A security team references the NIST Cybersecurity Framework 2.0 to anchor responsible reporting and governance practices within its broader security programme.
These examples show that the code is not only about courtesy. It is the practical control that keeps authorised testing from becoming uncontrolled experimentation, particularly when multiple teams, contractors, or external researchers are involved.
Why It Matters for Security Teams
A Code of Conduct matters because it turns permission into operational discipline. Without it, security teams may approve testing but still face unnecessary disruption, ambiguous evidence handling, inconsistent escalation, or conflicts over what a researcher may disclose. That creates avoidable friction in vulnerability management and can undermine trust between researchers and programme owners.
For identity-heavy environments, including NHI and agentic AI use cases, the stakes rise when testing touches credentials, tokens, API keys, service accounts, or autonomous agents with execution authority. A well-written code helps define how far researchers may go when validating exposure, and when they must stop to avoid crossing into unauthorised access or data handling. It also supports more reliable triage because reports arrive with clearer context and less contamination of evidence. Standards-based governance, including NIST Cybersecurity Framework 2.0, reinforces this approach by connecting behaviour to organisational risk management.
Organisations typically encounter the consequences only after a researcher causes service instability, mishandles sensitive artefacts, or publicly shares incomplete findings, at which point the code of conduct becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC | CSF 2.0 frames governance outcomes that support responsible security research conduct. |
| NIST SP 800-53 Rev 5 | PL-4 | Security planning controls support documented rules for acceptable testing behaviour. |
| NIST SP 800-63 | Digital identity guidance is relevant when conduct covers handling credentials and assurance evidence. | |
| OWASP Non-Human Identity Top 10 | NHI guidance applies where conduct governs testing of tokens, secrets, and service identities. | |
| NIST AI RMF | AI RMF applies when conduct controls how researchers interact with AI systems and agents. |
Define researcher conduct expectations inside governance and risk processes, then enforce them in programme operations.
Related resources from NHI Mgmt Group
- Why is hardcoding credentials into source code so dangerous?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between scanning AI-generated code and governing AI agent identity?
- When do AI-generated code and assistants increase secret exposure risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
