Skip to content
Kloudle
Kloudle Security

How We Do Security At Kloudle

Kloudle is founded by two experienced security experts. We have hacked, secured, tested 100s of cloud environments for customers ranging from Governments, Banks, LEA, Fortune 1000, Unicorns. With a combined experience of 35+ Years we understand how to maintain security as our highest priority.

Two things make up our security story: how we run our own product, and how the product treats your data. We follow security-by-default principles in everything we build and deploy. And because Kloudle is self-hosted, your cloud configuration, findings, and evidence stay in your environment — not ours.

We Practice What We Scan For

Our own infrastructure follows the same controls we check yours against. Zero-touch production, VPN-only access, 2FA everywhere.

  • All servers behind VPN — no open access
  • 2FA on all employee access, including build pipelines
  • Latest TLS on every internet-facing endpoint
  • Zero-touch production — no SSH, no manual deploys

Security First

Hardened · Audited · Verified

THE SECURITY MODEL

Your Security Context Is Yours to Hold

Kloudle turns raw scanner output into evidence-promoted security issues, stored in your environment, so humans stay responsible and agents act from proof. The labels below separate what is live today from what is near-term.

Your Findings Stay in Your Environment

Live today

Kloudle is self-hosted. The scanning engine runs on your own VMs, and your cloud configuration, findings, and pass/fail history are stored in your own PostgreSQL — a customer-controlled database that stays in your network. The fuller security context graph and evidence ledger are the model we are building on top of that evidence base.

Read-Only, Least-Privilege Access

Live today

The scanner reads cloud configuration with read-only credentials inside your infrastructure. Each scanner declares exactly which permissions it needs — no admin access, no write permissions by default.

Encrypted in Transit

Live today

Every connection — cloud provider API calls and dashboard traffic — is established over TLS 1.2 or higher. Data at rest is encrypted in the database you control, under keys in your environment.

Evidence-Promoted Issues, Not Raw Noise

Live today / near-term

Every check is readable SQL, and every finding carries the configuration evidence that produced it — no black-box scoring. Promoting findings into a governed issue queue with gates and waivers is being built on top of that evidence base.

Humans Stay Accountable

Near-term

In the model we are building toward, humans decide what counts as acceptable evidence, what blocks versus warns versus waives, and what agents are allowed to touch. Kloudle records those decisions in the ledger you own.

Agents Act Only From Proof and Policy

Near-term

Agents are meant to consume promoted, scoped issues from the ledger — never raw scanner output — and return proof of exactly what they changed. Agents help fulfill responsibility; they never own it.

Kloudle does not self-certify SOC 2. Regulated teams can use the findings and pass/fail history stored in their own database as evidence of operating discipline for their own audits. See how the ledger works and the security context graph.

SECURITY FAQ

Frequently Asked Questions about our Security

  • No. Kloudle does not have a Bug Bounty program, private or public. Neither do we offer swag for unsolicited security reports.

  • Although, active testing of Kloudle's app and infrastructure is not permitted, if you think you have found a security issue, you can report it in the following manner based on where the issue is present:

    •  1. If the issue is found in any kloudle owned online property, please send an email to security@kloudle.com
    •  2. If the issue is in the product, then you can raise the issue with our Engineering team directly through the app's feedback feature.

  • We do not consider vulnerability reports which do not include careful manual validation - for example reports based only on automated tools and scanners or repots that describe theoretical attack scenarios without proof of exploitability. This is a non-exhaustive list of reports that we don't consider to be a security problem across the website, the app and other KLOUDLE domains:

    1.  Exposed free trial
    2.  Bugs within the sandbox of the free trial (these are part of the product)
    3.  Any language, grammar or technical inaccuracy of Kloudle's findings or claims
    4.  Expired domains, SSL/TLS certificates or exposure of information via SSL/TLS certificate's Subject CN or via Certificate Transparency Logs.
    5.  Reports of broken links
    6.  Reports of unclaimed social media accounts
    7.  Disclosure of known public files or directories, (e.g. robots.txt)
    8.  Directory Listing
    9.  Images accessible via CDN and directly on the site
    10.  Cloud Account identifier information via JS/Images/Screenshots/Social Media/static files etc.
    11.  Security issues in third-party integrations within Kloudle (chat bot for example)
    12.  Caching related issues including cache poisoning and cache purging
    13.  Software version disclosure (disclosing the server is Apache or nginx etc.)
    14.  Service Banner identification issues (SSH version was identified etc.)
    15.  Descriptive error messages or headers (e.g. stack traces, application or server errors)
    16.  Full path disclosures due to error pages or verbose stack trace information
    17.  Missing CAPTCHA
    18.  HTTP 404 or other non-200 code pages
    19.  Exposed admin login panels
    20.  Leaked Kloudle email addresses
    21.  Metadata in PDFs, images etc.
    22.  Any automated scanner reports that are not validated
    23.  Static content over HTTP or "Mixed content" issues
    24.  Attacks requiring MITM or physical access or control over a user's device.
    25.  Modification of response content to display frontend app
    26.  Missing HttpOnly or Secure flags on cookies
    27.  Missing security headers in responses
    28.  Information in JWT being disclosed in header and payload sections
    29.  Session timeout related bugs
    30.  Relaxed CSP
    31.  Internal IP disclosure
    32.  Cookie valid after logout
    33.  Cookie valid after password change
    34.  Username/Email enumeration via login page or registration page status/error messages
    35.  Security bypasses in SSO when the bypass is with the Identity Provider (Google Auth bypass for example)
    36.  2FA/MFA bypass in auth provider when auth provider is not Kloudle
    37.  Social Engineering (phishing, attempts to steal cookies via fake login pages etc.)
    38.  Denial of service attacks (DDOS/DOS)
    39.  Issues related to rate limiting and Brute force issues on any API across the website and app
    40.  JS/webserver/framework or previously known vulnerable libraries
    41.  Reports of Keys or Tokens in JS unless it can be proven that the discovered can be exploited
    42.  Unminifying JS, reverse engineering and unobfuscation of client side JS
    43.  Same site scripting
    44.  Self XSS
    45.  Clickjacking anywhere on the site or the app
    46.  Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
    47.  Open Redirects
    48.  Vulnerabilities affecting outdated and unpatched browsers
    49.  Public zero-day vulnerabilities
    50.  CSV/Formula Injection
    51.  Tab nabbing
    52.  Spam/Flooding - Email, SMS or any other type of data flooding
    53.  Sub domain takeover issues without proof of concept
    54.  Sub domain takeover on domains that are not subdomains of app.kloudle.com
    55.  CSS hijacking or CSS injection
    56.  Public cloud buckets across any cloud provider
    57.  Leaked public keys
    58.  Hidden iFrame injections
    59.  Reports related to password strength
    60.  Reports related to information disclosed in GET parameters
    61.  Content Spoofing and Hyperlink Injection
    62.  Host header attacks
    63.  Issues with SPF, DKIM or DMARC records for kloudle.com or any other kloudle domain
    64.  Flash or Silverlight related security issues
    65.  GitHub public repositories


    Also, please use the CVSS 3.1 Calculator at https://www.first.org/cvss/calculator/3.1 to compute severity and only consider sharing of issues that are rated 8 or higher.

  • Yes. We encourage you to encrypt any sensitive information that you send to our security email address using GPG.
    Please use this key GPG Key.
    Key fingerprint - FA34 DE35 8B09 C828 D810 06D1 7B4B 7540 6E4B F413

  • Please send your queries to security@kloudle.com. We respond to security related queries only on this email. Expect a turnaround time of at least 3 to 4 business days. For any other information related to the product, signup, subscription, billing etc., please use our contact page.

We deeply care about cloud security.

We are small super technical team, dedicated to making sure you can secure your cloud effortlessly. We can do this by staying secure for ourselves and you.

Get Exclusive Access