Security & Trust

RunbookGuard runs entirely on Atlassian Forge. Customer data never leaves the Atlassian tenant. AWS access is granted via STS AssumeRole with a custom least-privilege policy — not the AWS-managed ReadOnlyAccess policy. No agent installed. No inbound network access from RunbookGuard into your environment.

The custom IAM policy — every action your role grants

Security teams correctly reject the AWS-managed ReadOnlyAccess policy because it includes s3:GetObject, secretsmanager:GetSecret*, kms:Decrypt, and dozens of other actions RunbookGuard never uses. Our CloudFormation template publishes a custom policy with exactly the 17 read actions we call.

The full policy, verbatim from cfn/v2/runbookguard-role.yaml:

Version: "2012-10-17"
Statement:
  # EC2 + VPC primitives
  - Effect: Allow
    Action:
      - ec2:DescribeInstances
      - ec2:DescribeSecurityGroups
      - ec2:DescribeSubnets
      - ec2:DescribeVpcs
      - ec2:DescribeRegions
    Resource: "*"

  # RDS, ELB, Route53, ElastiCache
  - Effect: Allow
    Action:
      - rds:DescribeDBInstances
      - elasticloadbalancing:DescribeLoadBalancers
      - route53:ListHostedZones
      - route53:ListResourceRecordSets
      - elasticache:DescribeCacheClusters
    Resource: "*"

  # ECS, EKS, Lambda
  - Effect: Allow
    Action:
      - ecs:ListClusters
      - ecs:DescribeClusters
      - eks:ListClusters
      - eks:DescribeCluster
      - lambda:ListFunctions
    Resource: "*"

  # S3 — METADATA ONLY (never s3:GetObject)
  - Effect: Allow
    Action:
      - s3:ListAllMyBuckets
      - s3:GetBucketLocation
    Resource: "*"

Total: 17 read-only actions across 9 AWS services. Zero write actions. No S3 object reads. No secret reads. No KMS.

Forge platform inheritance

RunbookGuard is built on Atlassian Forge — Atlassian's managed runtime for Cloud apps. We do not operate any infrastructure of our own. This has three concrete consequences:

1. We do not see your data. Forge runs your app inside your Atlassian tenant. The data RunbookGuard persists (extracted entities, findings, AWS inventory snapshots) lives in Forge SQL — Atlassian's per-tenant isolated SQL store — and never leaves your tenant.
2. We cannot deploy code that reads your data without an Atlassian-mediated update. Forge code is reviewed by Atlassian on every publish. New scopes require Atlassian to re-review.
3. You control uninstall. When you uninstall the app, Atlassian deletes all Forge SQL + KVS data within 30 days per Forge platform policy. We retain no copies — we couldn't, even if we wanted to.

Data residency — including EU

Forge data follows your Atlassian Cloud region setting. If your Confluence Cloud instance is configured for EU data residency, RunbookGuard's Forge SQL data is stored in the EU. The same applies to US, AU, Canada, and other Atlassian regions. RunbookGuard inherits this from Atlassian; we don't run a separate region tier.

For German enterprises specifically: this means RunbookGuard customer data does not leave EU infrastructure. Reference: Atlassian Cloud data residency.

Network model — no agent, no inbound

• No agent. Nothing is installed in your infrastructure. RunbookGuard runs entirely as a Forge Custom UI app inside Confluence.
• No inbound network access into your environment. RunbookGuard never opens a connection into your AWS account or your network.
• Outbound network is allowlisted at the platform level via Forge's manifest. RunbookGuard can only reach two destinations:
  • *.amazonaws.com — your AWS account, signed with the role you provided
  • api.resend.com — to deliver the weekly digest email to the address you configured
  Any other outbound destination is blocked by Atlassian's platform, not by RunbookGuard's code. The allowlist lives in our public manifest.yml.

AWS access — STS AssumeRole with External ID

RunbookGuard never holds long-lived AWS credentials for your account. The flow:

1. You create an IAM role in your AWS account (using our CloudFormation template) that allows RunbookGuard's service account to assume it, conditional on a per-install External ID.
2. Each scan, RunbookGuard calls sts:AssumeRole with the External ID and gets short-lived credentials (1 hour).
3. All inventory API calls are made with those temporary credentials, then discarded.

The External ID is generated per-install. If a different RunbookGuard customer somehow learned your account ID, they still cannot assume your role — they don't have the External ID.

Sub-processors

Compliance documentation

RunbookGuard is in early access. The following documents are in progress and will be linked here at the same URLs once published — bookmark these links for your audit-trail retention:

• SOC 2 Type II report — /security/soc2/ (in progress)
• Penetration test summary — /security/pentest/ (in progress)
• CAIQ v4.0.3 questionnaire — /security/caiq/ (draft available on request)

The Atlassian Forge platform itself holds SOC 2 Type II, ISO 27001, ISO 27018, and PCI DSS attestations. RunbookGuard inherits the platform-level controls. For platform compliance documentation, see Atlassian Trust Center.

Procurement timeline

For enterprises where Atlassian Cloud is on the already-approved-vendor list, RunbookGuard inherits that approval — there is no separate vendor-onboarding cycle. Billing flows through the Atlassian Marketplace, which most enterprise procurement teams treat as part of the existing Atlassian relationship rather than as a new SaaS vendor.

Median time from interest to install: 2-3 days. If your security team requires a separate review, the documentation on this page plus the published CloudFormation template typically completes the review in a single iteration.

Reporting a vulnerability

Email service@webcorrect.pro with subject line SECURITY:. We acknowledge within 24 hours. We do not currently run a paid bug-bounty program but credit researchers in changelog notes by request.