A Security Fix, a Copied Snippet, and a Silent Upstream
Security scanning flags a Java deserialization vulnerability in an Apache-2.0 library hosted at a foundation; the bank embeds that library in a payment routing service running in production. The library has two maintainers, both employed by another bank, a last release five months ago, and eleven pull requests that have not been reviewed. The bank's vulnerability policy requires a remediated build within 30 days. A developer on the payments team has produced a patch that rejects the offending gadget class and adds a regression test. Reviewing the diff, an architect notices that the sanitisation method was copied from a Stack Overflow answer, and the developer confirms it. The vulnerability is not yet public and no advisory exists. The developer wants to open a public pull request today, arguing that speed matters more than process and that the maintainers will see it faster.
1. How should the vulnerability be disclosed and fixed, given the 30-day internal deadline?
Read the worked answer
Do not open a public pull request. A public PR is a full disclosure: it names the vulnerable class, shows the exploit path, and starts a clock you do not control. Anyone watching the repository can weaponise it before consumers have patched.
Sequence:
- Read SECURITY.md and use the private channel. If there is none, use GitHub's private security advisory feature on the repository, or contact the foundation's security team directly.
- Ask the maintainers to open a draft advisory so the reporter, maintainers and downstream consumers can coordinate in private. Request a CVE - through the maintainers, or through the foundation if it is a CNA, otherwise MITRE.
- Share the patch privately in a temporary private fork or as an attachment, with a reproduction case and the regression test.
- Agree a disclosure date, typically 90 days, shortened if there is evidence of exploitation.
- Fix the bank's own exposure in parallel, not after. The 30-day SLA must never depend on two volunteers at another bank. Options: a class-allowlist filter at the deserialization boundary in the calling service, a network control, or a vendored patched build.
- Escalate on a timer: if there is no maintainer response within about seven days, go to the foundation and notify other known consumers under embargo.
Speed and disclosure are not in conflict if you run the mitigation and the coordinated fix as two tracks.
2. The copied Stack Overflow snippet: what is the actual problem, and what would you do about it?
Read the worked answer
The problem is a licence conflict, not plagiarism. Code posted on Stack Overflow is licensed under CC BY-SA (version 4.0 for content posted after the change), which is a share-alike licence. Meanwhile the surrounding method is Apache-2.0. You cannot relicense CC BY-SA material under Apache-2.0, and attribution alone does not cure it: share-alike would reach the derivative work. Many corporate contribution policies ban CC BY-SA snippets outright for this reason.
What I would do:
- Delete the copied method rather than trying to attribute it.
- Re-derive the sanitiser from the specification: the list of permitted classes, the parsing contract, and the OWASP guidance on deserialization. A developer writing an allowlist from a specification will almost certainly produce a safer implementation than a snippet written for a different context - snippet code is often incomplete on exactly the edge cases that matter.
- If a specific algorithm is genuinely needed, find a source under a permissive licence (Apache-2.0, MIT, BSD) and record the origin and licence in a third-party notices file.
- Have the reviewer check the whole diff for other pasted fragments, not just this method.
"It's only five lines" is not a defence a bank's IP review will accept. If the copied code did reach a public PR and was merged, it would need to be removed upstream and the incident recorded.
3. Under what conditions would you fork rather than keep pushing upstream, and what would the fork commit the bank to?
Read the worked answer
Run three tracks at once: mitigate internally, coordinate the advisory, and decide on the fork only when you have evidence about maintainer responsiveness.
Fork publicly only if: the maintainers have not engaged within the coordinated window; the vulnerability affects other consumers who need a patched artefact; and the bank can name at least two engineers, a build pipeline and a security response process to carry it. A public fork that dies in six months is worse than no fork, because downstream users switch to it.
Prefer, in order: getting the patch merged and a release cut; funding or seconding a maintainer to the project; joining the project as a committer so the bank has standing for future fixes. A fork is the expensive option and should be chosen because the alternative failed, not because it is faster this week.
What the fork commits the bank to:
- A distinct artefact name or coordinate so consumers cannot confuse the fork with upstream, and an explicit statement of the relationship.
- A version scheme that does not collide, plus clear advisories so a CVE is not left half-fixed across two codebases.
- Ongoing maintenance: triage, releases, security contact, and a published policy for merging upstream changes back in.
- A revisit trigger - if upstream revives and ships a fix, converge rather than diverge permanently.
Also check the paperwork: a corporate CLA or DCO sign-off is likely needed before the bank's patch can be accepted, and sign-off authority sits with the program office, not the developer. Route it on day one so the legal step is not what delays the fix.