YPCad
English (US)
Request a demo

Security

This page states both what we protect and what we cannot. A security story that leaves out the second part invites the reader to mistake a list for a guarantee.

The starting point

Publishing a package means running code on every engineer’s machine that installs it. Every security decision in this product was weighed against one question first: does this change make unauthorized publishing easier?

  • Packages are signed (ECDSA P-256)

    The signature file travels inside the package. It signs a manifest containing the file hashes, package identity and version — not a bare archive hash.

    If only the hash were signed, a validly signed old archive could be listed under a new version number: the signature would verify and the user would install a known-vulnerable tool as an “update”.

  • The private key is NOT on the server

    The server only verifies. Signing happens on the publisher’s own machine with a separate tool.

    If the key sat on the server, whoever took over the server could alter a package and re-sign it — which would make signing pointless.

  • The client verifies too

    The add-in on the engineer’s machine checks the signature independently, and the list of trusted keys it uses does not come from the server.

    Signing exists because the server cannot be taken at its word. Fetching the trust list from that same server would quietly cancel the assumption.

  • An audit trail that cannot be deleted

    Every release, entitlement change and channel decision is written permanently. There is deliberately no update or delete path, and retention cleanup does not touch it.

    “How did this tool get here” is usually asked months later. On that day, a record that could be deleted is a record that never existed.

  • Optional four-eyes rule

    Promoting a version to a wider channel can require a second administrator’s approval, and the requester cannot approve their own request. Rolling back never requires approval.

    It is off by default. In a three-person team the gate turns into a message that gets approved without being read within weeks; a control believed to protect when it does not is worse than no control at all.

  • Extracting an archive is itself an attack surface

    Uploaded archives are checked for path traversal (zip-slip) and decompression bombs, and the extracted size is capped.

    Extracting an archive looks harmless. A crafted one can write files outside the target folder or fill the server’s disk.

  • Passwordless sign-in

    Users sign in with a one-time code sent to their email address. The session runs on a short-lived token; the refresh token is never visible to browser code.

    With no password pool to manage, there is no password database to leak. And reuse of a revoked refresh token is treated as a theft signal: the session is dropped.

  • You can see what you are installing

    The installation folder ships a machine-readable bill of materials (CycloneDX SBOM) and migration scripts for both database engines.

    Your IT team should be able to review what goes onto the server before it goes on. When a dependency is disclosed, “do we have it” becomes a file search.

What we cannot protect

These are not gaps, they are limits. They follow from the structure, and claiming otherwise would be untrue.

  • Two administrators acting together. The four-eyes rule stops one person, not two.
  • The server’s system administrator. For someone with database and file system access, no application-level control is an obstacle.
  • The workstation holding the signing key. The key is not on the server, but it is somewhere; if that machine falls, so does the signature.
  • Deliberately hidden malicious behavior. Our package inspection is heuristic and we do not claim it will catch code that is trying to hide.
  • Data exfiltration. An installed tool runs with the engineer’s own permissions and can read anything those permissions reach. Operating system and network controls limit that, not this product.
  • The safety of your backups. The database backup is in your hands, and everything in it is exactly as valuable as the live system.

Reporting a vulnerability

If you have found one, write to us. We take reports seriously, we do not shut the reporter out of the process, and we tell you when the fix ships.

security@ypcad.com