Security Overview

Security is not just a feature. It’s our mission.

Every design decision in Socket begins with the safety and privacy of your data in mind. We can't read your source code, and no one else can either. Privacy isn’t an optional mode — it’s just the way that Socket works.

Our commitments to you:

• We never upload your source code
• We never modify your source code
• We use industry-leading security practices across our services
  • Security Certifications
  • Security Audits
  • Web Security Measures
• We take precautions to keep your report data safe
• Our team takes security seriously

We never upload your source code

Socket is designed to work without the need to analyze, upload, or share your source code.

• The only data we collect from your repository is the package.json file and associated lockfiles such as package-lock.json and yarn.lock, which we call the dependency snapshot.
• We use the dependency snapshot to determine the list of packages used by your repository, perform our open source risk analysis, and produce a report.
• The exact list of files that Socket reads from a repository and uploads to socket.dev are:
  • package-lock.json
  • package.json
  • pnpm-lock.yaml
  • socket.yaml
  • socket.yml
  • yarn.lock

We never modify your source code

Under no circumstances will we ever modify a customer’s source code or deployment environment.

• We do not request these permissions, nor do we ever use them.
• In the event our service is compromised, your source code will not be affected

We use industry-leading security practices across our services

Security Certifications

• Mozilla Observatory rates our website configuration an A+. See report.
• Qualys SSL Labs rates our TLS implementation a A+. See report.

Security Audits

Socket intends to regularly contract security consultants to ensure the security of our services and customer data. Security consultants perform regular security audits and infiltration testing. Any issues that are reported to our security team or raised during security audits will be resolved as soon as possible.

Web Security Measures

• We secure all communication to our servers using TLS
  • Transport Layer Security (TLS) is the industry-standard encryption protocol used to encrypt communications between you and our servers. It ensures that data you send to the Socket service cannot be observed or modified by a network attacker. It is believed to be infeasible for an adversary to man-in-the-middle or snoop on communications to our service.
  • We support TLS 1.3 for modern devices and TLS 1.2 for all remaining devices. Deprecated versions of TLS and SSL are not used.
  • We monitor the Certificate Transparency logs for certificate misissuance. Certificate transparency aims to mitigate the problem of misissued certificates by providing publicly auditable, append-only, untrusted logs of all issued certificates.
• We use a CAA policy to reduce the risk of unintended or malicious certificate misissuance.
  • A Certification Authority Authorization (CAA) policy allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain.
• We deploy DNSSEC to protect DNS records for our domains
  • DNSSEC is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity.
• We deploy the latest HTTP security measures to protect our web applications
  • Strict-Transport-Security
    • Socket uses this header to ensure that your browser always communicates with our servers using the TLS protocol.
    • We additionally include all our domain names in all major browsers HTTP Strict Transport Security (HSTS) preload lists.
  • Permissions-Policy
    • Socket uses this header to disable web browser features that we don't need, like camera and microphone access.
  • Content-Security-Policy
    • Socket deploys a strict Content Security Policy to defend against XSS (cross site scripting) attacks. Our CSP policy prevents our app from being tricked into accessing resources (such as scripts, webpages, etc.) that could be used in XSS attacks.
    • Our CSP is a very strict policy that blocks execution of inline JavaScript, JavaScript's eval() function, browser plug-ins, active and passive HTTP content, clickjacking attacks, <base> tag attacks, <form> submissions to exfiltrate data, and more.
• We isolate user hosted content on a separate origin from the main website origin
  • The user content origin (socketusercontent.com) has the strictest possible Content Security Policy, fully sandboxing it and preventing it from executing any user-provided code or from loading additional subresources.
• We enforce rate limits against all key endpoints to limit the impact of denial-of-service attacks.

We take precautions to keep your report data safe

Your data is end-to-end encrypted to keep it safe in transit. We use multiple techniques to make sure only you have access to your information. We're continuously working to make sure our code is rock solid.

• All reports are authenticated using the SHA2 hash of the dependency snapshot
  • This means that only agents who know the contents of the dependency snapshot are capable of accessing a report
    • This data is necessary and sufficient to generate a report: If an adversary knew the contents of these files, then they could just register a new account and request their own report.
    • Any further authentication would be security theater, and any less authentication would increase risk.
  • If a user loses or forgets this hash, then they will not be able to retrieve their report.
    • Though they could create a new report using the current state of their project.
  • We do not provide any index for users to search through all reports.
• We use AWS S3 for storing all reports, and we use Render for hosting our web servers.
  • These are industry standard hosting solutions and considered very secure.
  • S3 buckets have the minimum necessary permissions.
• At the request of a customer, we can remove any report or accidentally uploaded data from our system
  • It may take some time for this removal to propagate to caches on client browsers and we make no guarantees on how long these effects will take to complete.

Our team takes security seriously

Feross Aboukhadijeh – Founder and CEO, Socket

• Teaches CS 253 Web Security at Stanford University
• Masters in Computer Science (Networking and Security) from Stanford University

Dan Boneh – Investor and Advisor, Socket

• Professor of Computer Science and Electrical Engineering, Stanford University
• Co-director of the Stanford Computer Security Lab

We have many investors with security industry experience:

Andrew Peterson – Signal Sciences founder

Balaji Srinivasan – Counsyl founder, Coinbase CTO, a16z Partner

Fred Ehrsam – Coinbase founder, Paradigm managing partner

Freddy Kerrest – Okta founder & COO

Haroon Meer – Thinkst founder

Max Krohn – Keybase founder, Zoom Head of Security

Nat Friedman – Former GitHub CEO

Ryan Noon – Material Security founder

Todd McKinnon – Okta founder & CEO

Zane Lackey – Signal Sciences founder

Additional questions

If you have questions or concerns not addressed in this document, please reach out to us at security@socket.dev and we’ll be happy to help.

You can also visit our security vulnerability disclosure page.