How Apivom Thinks About Source Code Security

Most security pages list controls and stop there. This post explains what we do about our own source code, what we inherit from the platforms we build on, and what we do not claim.

Three practices on two platforms

Apivom's code lives on GitHub Enterprise Cloud, and the live platform runs on Microsoft Azure. We back that with three non-negotiable practices:

• Automated dependency vulnerability scanning on our repositories, using GitHub Dependabot.
• Two-factor authentication enforced for every engineer with source code access.
• A web application firewall (WAF) and DDoS protection in front of the live platform, using Azure Front Door Premium.

The sections below break each one down, then draw the line on what we do not claim.

Dependency scanning: most of your code is someone else's

A modern application is mostly other people's packages. Each one is code we ship, so a known vulnerability in a dependency is a vulnerability in our product, even if we never wrote a line of it.

Dependabot checks our repositories' dependencies against published security advisories. When a package we use has a known vulnerability, it raises an alert and, where a fixed version exists, opens a pull request to update it. That pull request goes through the same review and quality checks as any other change.

The scanning is automatic and always on, so nobody has to remember to run it. The fix is an ordinary pull request, so it does not need a special process.

Its limits, stated plainly: Dependabot catches known vulnerabilities in dependencies. It does not review the code we write, and it cannot catch a flaw nobody has reported yet. We treat it as one layer in a stack, not a guarantee.

Two-factor authentication for everyone who can touch the code

Access to source code is among the most sensitive access an engineering team holds. A stolen password for an account that can change code is a path toward production.

So we enforce two-factor authentication across our GitHub organization for every engineer with source code access. It is a requirement, not a recommendation. Recommended settings erode over time, while a requirement needs no follow-up.

We wrote about the same principle for partner access in Passkeys for Partner API Access: tie a credential to a person, and the audit trail starts to mean something.

What GitHub's certifications do and do not mean

Our source control, code review and automation run on GitHub Enterprise Cloud. GitHub holds SOC 1 Type II, SOC 2 Type II and SOC 3 reports, ISO/IEC 27001:2022, ISO/IEC 42001:2023 and PCI DSS certifications. It also commissions third-party penetration tests and runs a bug bounty program.

Those certifications cover GitHub's own infrastructure and operations. They do not certify Apivom. We do not currently hold our own SOC 2 or ISO/IEC 27001 certification. What we will say with confidence: the platform our code lives on is independently audited, and our own practices are laid out here in full so you can hold us to them.

The live platform: Azure Front Door in front

Apivom's application infrastructure runs on Microsoft Azure, in West Europe by default, or in your own Azure tenant when you need full control over where data lives. Public traffic reaches the platform through Azure Front Door Premium, with a WAF and DDoS protection.

A WAF filters requests before they ever reach the application, cutting exposure to common attack patterns and automated abuse. It is not a substitute for secure code — which is exactly why the practices above exist.

What we do not claim

• We do not hold our own SOC 2 or ISO/IEC 27001 certification.
• GitHub's certifications belong to GitHub, not to Apivom.
• Dependency scanning finds known vulnerabilities. It does not find unknown ones.
• None of this replaces your own due diligence.

Four questions to ask any vendor

1. Is dependency scanning automatic, or does someone have to remember it?
2. Is two-factor authentication enforced, or only recommended?
3. Whose certification is it: the vendor's, or its hosting platform's?
4. Where does public traffic enter, and what filters it?

Running a security review? Ask us these same four questions — we expect to answer them. Our disclosure policy and security contact are on the security page, and you can read more about the company on the about page.