Senior · Modules and tooling
Private dependencies and supply chain
How do you keep private module names and credentials out of public services?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Configure the private module patterns and appropriate proxy/checksum behavior before fetching. GOPRIVATE is a policy input for module handling; it is not a credential store or access grant.
Use scoped credentials via the supported transport, never embed tokens in module paths, committed URLs or Docker layers. Keep CI secrets out of logs and untrusted build steps.
Review module graph changes, hashes and supported toolchain versions. Pin build inputs and scan reachable vulnerabilities with current tooling, but distinguish an advisory match from an exploitable path and do not promise that a scan proves safety.
Common trap
Turning off checksum verification globally to fix one private dependency weakens verification for public dependencies too.
Try it
A CI build prints a Git URL containing a token. What is the immediate and durable repair?
Worked solution
Revoke/rotate the exposed credential, restrict log access as appropriate, then move authentication to a secret mechanism that does not appear in source or command output. Review the build path before rerunning; do not paste the token into an agent prompt.
Change the constraint
How can an unreviewed dependency or build script read credentials present in its environment?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.