Privacy

Who is responsible

SecureYet is in beta, run from Copenhagen, Denmark. When it leaves beta, a company will take over as the responsible entity, and this page will name it. What SecureYet reads from the repositories and trackers an organisation connects is processed on that organisation's behalf: the organisation decides what is connected and can remove it at any time.

Questions and requests: [email protected].

What SecureYet stores, and why

• Your account. Name, email address, profile picture and which organisations you belong to, so you can sign in and your colleagues can see who did what.
• Sign-ins. When you signed in, with browser, device type and country, so support can help when something goes wrong. Kept for 90 days.
• Activity log. What was done in your organisation, by whom, and from which IP address, so admins and support can find out how something changed.
• Connections to code hosts. The GitHub App installation, or the access token for Azure DevOps or GitLab, so SecureYet can read the repositories you choose. Tokens are stored encrypted.
• Scan results, not code. To scan a repository SecureYet downloads it and reads it as it arrives. It does not keep the code. It keeps what the scan found: the kind of problem, the file and line, packages and their versions, licences, runtimes and the AI models the code calls. For a committed secret it keeps a masked sample, never the secret itself.
• Jira. When an admin connects Jira: the Atlassian account ID and display name of the account that connected, and an encrypted token, so SecureYet can create issues and read their status. The issues it writes describe the problem and link back to SecureYet. They never contain a secret value.
• Your settings. Which emails you receive, and the choices your organisation makes in SecureYet.

SecureYet uses no advertising or analytics trackers. The only cookies are the ones Clerk needs to keep you signed in.

Who else receives it

SecureYet runs on its own servers in Copenhagen, Denmark. These services receive personal data to do their part:

Transfers to the USA rely on the EU-US Data Privacy Framework or the European Commission's standard contractual clauses.

The services your organisation connects (GitHub, Azure DevOps, GitLab, Atlassian) receive only what SecureYet asks them for, under your own agreement with them. To look up vulnerabilities SecureYet downloads the public OSV database; nothing about you or your code is sent. To read licences it asks the public package registries about package names and versions. The AI model that judges whether a found secret is real runs on SecureYet's own servers: no code or finding is sent to an outside AI service.

How long it is kept

• Scan results and the activity log: as long as your organisation uses SecureYet. Removing a repository hides it and keeps its history, so it can be restored.
• Sign-ins: 90 days.
• A connection's token: until the connection is removed, which deletes it.
• When an organisation is deleted it is locked for 30 days, so a mistake can be undone, and then everything it holds is deleted, along with the accounts of people who belonged to no other organisation. What remains afterwards names no one: its size and plan for our own numbers, its activity log with people replaced by "deleted user" and no IP addresses, kept 12 months for security investigations, and billing records for as long as Danish bookkeeping law requires.
• When you delete your account, your name, email address and profile picture are erased at once.

Your rights

You can ask to see the personal data SecureYet holds about you, to have it corrected or deleted, to receive a copy, or to object to how it is used. Write to [email protected]; you will get an answer within a month. If the data belongs to an organisation's account, its admins can also export or delete it in SecureYet.

Changes

When SecureYet starts storing something new or uses a new service, this page changes first. The date at the top says when it last did.