Application Security When You Ship Code You Don't Own

On some engagements you own the repo and the org; on others you are a contributor inside a client's existing GitHub organization with no say over which security tools are enabled at the org level. Snyk works from outside GitHub's permission model, so you can run it against a client repo you have read access to even when you cannot install a GitHub App at the org level. GitHub Advanced Security, by contrast, needs to be turned on by whoever administers that organization, which means your rollout plan has to start with a conversation, not a config file.

Trying to force every client onto the same scanner is a losing fight when half your clients already have GitHub Advanced Security licensed and the other half have nothing. A more durable approach is to standardize the policy: every project gets dependency scanning, every critical finding gets a ticket, every ticket gets a fix date before launch. Whether that policy runs through Snyk or through the client's own GitHub setup matters less than whether it runs at all.

Clients rarely ask for a specific remediation timeline up front, which means you get to set the bar. A two-week window for critical findings on anything internet-facing is a reasonable default to put in writing, and it protects you too: if a client's stakeholder later asks why a flaw shipped, you have a documented policy to point to instead of an informal habit that nobody wrote down.

Teams with a mature deployment pipeline also tend to see a lower change failure rate than teams without one, a pattern the DORA research tracks across performance clusters¹. A written SLA and a reviewed pipeline tend to move together, so building one habit reinforces the other.

The riskiest moment in a client engagement is the last week, when your team is focused on the launch and the client's team has not yet taken ownership of the security tooling. Before the project closes, hand over a short document: which scanner is running, who gets the alerts now, what the open findings list looks like, and what the agreed remediation SLA was. A client who inherits a clean, documented queue is far more likely to keep the habit going than one who inherits a tool they don't know how to log into.

A short handoff document should cover:

• Which scanner is running on the repo, so the client knows what produces the alerts once your team has left.
• Who receives the alerts now, named as a person or role on the client side rather than left as an assumption.
• The current list of open findings, with severity and ticket status, so nothing is quietly lost in the transition.
• The remediation SLA that was agreed in the statement of work, so the client can keep to it after you roll off.

For a shop juggling several client stacks, Snyk's strength is that it does not care which platform a repo lives on, so your internal team can build one dashboard across every engagement regardless of which client owns the org. GitHub Advanced Security's strength is the opposite: if a client is already fully invested in GitHub, turning on native scanning adds zero new logins for their team to manage after you leave, which is often the deciding factor for a client who wants the smallest possible footprint of contractor tooling once the engagement ends.

Security review time is easy to underestimate when scoping a fixed-bid proposal, and it's one of the first things cut when a project runs over budget. Build a specific line item for setting up scanning, triaging the first pass of findings, and writing the handoff document, rather than folding it into general development time where it competes with feature work for attention.

On a time-and-materials engagement, this is simpler: track the hours separately so the client can see exactly what the security work cost, which also makes it easier to justify continuing the practice on the next project rather than treating it as a one-off favor. A studio that can point to a specific, billable line item for this work tends to keep doing it consistently across engagements, while one that treats it as unbilled overhead tends to let it slip the moment a deadline gets tight.