Skip to content

PENTEST.md

Latest commit

 

History

History
102 lines (80 loc) · 4.31 KB

PENTEST.md

File metadata and controls

102 lines (80 loc) · 4.31 KB
Raw

CT-Ops Penetration Testing Scope

This document defines the engagement scope and rules of engagement for authorised penetration testing of the upstream CT-Ops project hosted at https://github.com/carrtech-dev/ct-ops.

It is intended to sit alongside SECURITY.md and SECURITY_DISCLOSURE.md so researchers, customers, and internal reviewers have one place to confirm what may be tested, how to make contact, and what boundaries apply.

Contacts

Use these contacts before or during a planned test window:

Do not file public GitHub issues for live security findings discovered during a test. Route them through the private channels above.

In-Scope Targets

The following upstream project components are in scope when you have explicit permission to test them:

  • Repository source code in carrtech-dev/ct-ops
  • Web application under apps/web/
  • gRPC ingest service under apps/ingest/
  • Queue consumers under consumers/
  • Go agent under agent/
  • Installer, startup scripts, and packaged container images
  • Official deployment assets under deploy/, docker-compose*.yml, install.sh, and start.sh
  • Protocol definitions and shared packages under proto/ and packages/
  • Default security surfaces shipped by the project, including authentication, session handling, authorisation, agent enrolment, certificate tooling, notification delivery, and instance isolation

Allowed Test Activities

The following test categories are in scope when executed carefully and within the rules below:

  • Authentication, session, and access-control testing
  • Instance-boundary validation validation
  • Input validation, injection, SSRF, deserialisation, and file-handling tests
  • Deployment and container-hardening review
  • Agent, ingest, and API protocol security testing
  • Dependency and supply-chain validation tied directly to the shipped project
  • Limited proof-of-concept exploitation needed to demonstrate impact

Rules of Engagement

All testing must follow these rules:

  • Test only systems, environments, and accounts you own or have explicit written permission to assess.
  • Prefer local, staging, or isolated customer-approved environments instead of shared production systems.
  • Keep request volume low and avoid volumetric denial-of-service techniques.
  • Do not access, modify, exfiltrate, or retain data that is not required to prove the finding.
  • Stop immediately and contact the security team if you encounter real customer data, secrets, or a path that could cause service-wide instability.
  • Do not pivot from a CT-Ops deployment into unrelated third-party or internal infrastructure.
  • Do not social-engineer maintainers, operators, customers, or support staff.
  • Do not publicly disclose findings until a remediation and disclosure timeline has been agreed.

Out-of-Scope Targets

Unless the project owner gives explicit prior written approval, the following targets and activities are out of scope:

  • Third-party infrastructure not owned by the tester, including cloud accounts, mail relays, LDAP directories, chat platforms, and external webhooks reached from a CT-Ops deployment
  • Carrtech or customer corporate endpoints unrelated to CT-Ops itself
  • Physical attacks, phishing, vishing, pretexting, or credential stuffing
  • Volumetric denial-of-service, resource-exhaustion floods, or destructive availability testing
  • Any attempt to access data belonging to other users, customers, or instances beyond the minimum proof needed to demonstrate isolation failure
  • Attacks that require already having root or equivalent privileged access on a host, unless the assessment is specifically scoped to post-compromise impact
  • Findings that depend only on unsupported forks, local patches, or operator misconfiguration outside the shipped defaults

Test Window Expectations

For coordinated engagements, provide the following before testing starts:

  • Environment URL or deployment identifier
  • Intended start and end dates in UTC
  • Source IP ranges where practical
  • Tester contact details
  • Named point of contact for urgent stop or escalation requests

If you are unsure whether a target or technique is in scope, ask the security contact before testing it.