Secure Software Development

Triaging a Dependency Advisory

The supply-chain check in CI produces a list, and the list needs triage before it needs work. The first question is what actually shipped: the manifest declares a version range, the lockfile records the resolved version, and a scanner pointed at the manifest can report a different answer than the one running in production. The second question is reachability. A vulnerability in a parser your application never calls, reached only through an option that is off by default, is not the same finding as one in the code path that handles uploaded files, even when the two carry the same score. A severity rating is calculated against an assumed deployment, and yours may not be it.

The upgrade path is usually the real work. When the patched release exists only for a major version you are not on, the fix stops being a version bump and becomes a migration, and the interim choices are a pinned build, a configuration change that closes the exposed path, or a control at the edge that blocks the input shape. Each of those is defensible with a date attached to it and indefensible without one, because the temporary measure is what survives when nobody revisits the ticket.

• Is the package a direct dependency, or transitive, and can it be resolved by upgrading the parent rather than forcing an override that the parent was not tested against?
• Does the application call the affected function at all, and is the input reaching it attacker controlled?
• Does the advisory assume a configuration you actually run: a particular parser, a server mode, a feature flag, an option that ships disabled?
• Is it in the known exploited catalog, which is the strongest argument for treating it as urgent whatever your reachability analysis says?
• Does a fixed release exist for the major version you are on, or does the fix require a framework migration and its own test plan?

Secrets, and What Rotation Means

Deleting a secret from a file does not end the exposure. The value is still in the git history, and it is also wherever it already traveled: build logs, container image layers, a developer's shell history, a clone somebody made last year, a backup of the repository. The only action that ends it is rotating the credential at whatever issued it. Rewriting history is cleanup, and it belongs after rotation rather than instead of it. A rotated secret is also only an improvement if the replacement is not stored the same way the original was.

The direction that removes the problem rather than managing it is short-lived credentials. A CI job can federate to a cloud account through OIDC and receive a token scoped to that run, so the pipeline holds no long-lived access key at all, and the trust lives in a policy in the cloud account that names the repository and the branch. That policy is worth reading character by character, because a subject condition written to match the organization but not the repository lets any repository in the organization assume the role. Databases and internal services can reach the same place with short-lived certificates or a broker that issues per-session credentials, which turns a leak into a problem with an expiry time.

Gates in the Pipeline

A gate that blocks a merge has to be trustworthy or it gets switched off, and the team learns that security checks are noise. The way to arrive at a blocking gate is to start advisory, baseline the findings that already exist so the gate applies to new code, and promote rules to blocking one at a time as their false positive rate becomes known. A gate on what the diff introduces is enforceable in a way that a gate on the whole repository's backlog is not, because the developer holding the pull request can actually act on it.

Secrets detection is the exception that belongs as early as possible, ideally before a push reaches a shared remote, since once a value lands on a remote branch rotation is required regardless of what happens next. The pipeline configuration deserves review of its own. A workflow that runs in the base repository's context so it can read secrets, and then checks out and executes the code from a pull request branch, hands those secrets to anyone who opens a pull request, and this is a well known way to give them away. Log masking helps but is best effort: it matches the literal value, so a secret that has been base64 encoded, concatenated, or split across variables prints in the clear.

Placement matters as much as choice of tool. Checks measured in seconds belong on every push, checks measured in tens of minutes belong on a schedule or a release branch, and anything that needs a deployed environment belongs after deploy to staging rather than in front of the merge. A check in the wrong place is not a stricter program, it is a slower one that people learn to route around.

Defaults That Get Defeated

Frameworks ship safe defaults, and a large share of what a review finds is a place where somebody turned one off deliberately, for a reason that was reasonable that afternoon. The query builder parameterizes everything except the one raw string that was needed for a dynamic sort column. The template engine escapes output everywhere except the filter that marks a value safe, added so a rich text field would render. The CSRF middleware is exempted on one endpoint so a partner could post to it, and the exemption outlives the partner by years.

This is what makes an inventory of exemptions a productive early step: the escape hatches have names, they are searchable, and each one comes with a question about who defeated the default and why. The finding worth writing up is rarely that the escape hatch exists. It is that nobody left a reason, and the condition that justified it is no longer true.

• A template filter marking a string as safe, wrapping a value that originated with a user.
• A CSRF exemption on an endpoint that still authenticates with a session cookie, which is what the protection existed for.
• An HTTP client built with certificate verification disabled, usually left behind from a staging environment with a self-signed certificate.
• CORS configured to reflect the request Origin header with credentials allowed, which is equivalent to accepting every origin.
• A concatenated raw query sitting next to an ORM used correctly in the rest of the file.
• A route missing the authorization decorator that every sibling route in the controller carries.

Which Engagement Fits

The choice between a review and a test is usually settled by what you already know. If the question is whether authorization is enforced on paths a tester would have to guess the existence of, reading the code reaches them and a black-box test may not. If you already hold a list of suspected problems, fixing them and testing afterward gets more out of the test, because a test aimed at known unfixed issues spends its budget confirming a list you already had.

Compliance readiness is a third question and it is worth keeping separate. An assessor asking for evidence of a secure development process is asking about the process: who approves changes, what the pipeline enforces, how findings are tracked to closure. That is different work from establishing what the code actually does on a given path. Teams often arrive asking for one when the date on the calendar requires the other, and the fastest way to tell them apart is to look at who is waiting for the answer.

There are cases where the honest answer is a different kind of work entirely. If the application is a thin layer over managed services and most of what you own is configuration, then reading IAM policies, storage permissions, network rules and identity provider settings will find more than reading application code will. And if there has never been a conversation about trust boundaries, that conversation should come before either engagement, because it changes what the scope ought to include.