Protect source code with several controls working together: keep it in a centrally managed private repository, give named users only the access they need, keep credentials outside the codebase, review changes before they merge, and restrict what automated build workflows can access. Add dependency and code scanning, audit access and changes, and remove access promptly when someone leaves. A private repository is one layer—not a complete security plan.
Who should be able to read or change the code?
Start with the repository and its permissions. NIST guidance on protecting software artifacts calls for least-privilege access to source code, executables, and configuration-as-code. That limits both unauthorized changes and unauthorized acquisition of code. NIST describes preventing unauthorized people from obtaining source code as a way to reduce the risk of competitors copying it or attackers using it to find weaknesses.
Use named accounts and grant the minimum access
- Store code in a centrally managed version-control system, and keep repositories private when their contents are not meant to be public.
- Give each contributor an individual account rather than sharing credentials. Assign read and write permissions according to the work each person needs to do.
- Limit administrator access. People who only need to review or read code should not receive permission to change repository settings or merge changes.
- Review membership and permissions regularly, and remove access as soon as a person no longer needs it—including when a contractor or employee leaves.
These controls apply whether the repository is on GitHub, GitLab, or another hosted or self-managed platform. A “private” setting controls who can access the repository through the service; it does not by itself prevent an authorized user from copying code or protect credentials exposed elsewhere.
Protect the paths that control the repository
Treat access-policy files, deployment configuration, and CI workflow definitions as high-impact code. A change to these files can alter who gets access, where code is sent, or what runs during a build. Restrict who can approve changes to them and include them in the same review and audit process as application code.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →#1 Best Overall
- High-speed USB 3.0 performance of up to 150MB/s(1) [(1) Write to drive up to 15x faster than standard USB 2.0 drives (4MB/s); varies by drive capacity. Up to 150MB/s read speed. USB 3.0 port required. Based on internal testing; performance may be lower depending on host device, usage conditions, and other factors; 1MB=1,000,000 bytes]
- Transfer a full-length movie in less than 30 seconds(2) [(2) Based on 1.2GB MPEG-4 video transfer with USB 3.0 host device. Results may vary based on host device, file attributes and other factors]
- Transfer to drive up to 15 times faster than standard USB 2.0 drives(1)
- Sleek, durable metal casing
- Easy-to-use password protection for your private files(3) [(3)Password protection uses 128-bit AES encryption and is supported by Windows 7, Windows 8, Windows 10, and Mac OS X v10.9 plus; Software download required for Mac, visit the SanDisk SecureAccess support page]
How should you keep secrets out of Git?
Do not put passwords, API tokens, signing keys, certificates, or other credentials in source files or CI/CD configuration. OWASP’s CI/CD Security Cheat Sheet states: “Secrets should never be hardcoded in code repositories or CI/CD configuration files.” Treat a credential committed even briefly as exposed: removing it in a later commit does not erase it from earlier repository history or copies already made.
Store and grant secrets separately
- Use an encrypted secret-management service outside the repository rather than committing credentials, placing them in workflow YAML, or embedding them in images or binaries.
- Give each secret the narrowest scope and permissions that support its task. Avoid using a broad, long-lived credential when a limited one will do.
- Prefer short-lived credentials where the platform and workflow support them.
- Keep secrets out of logs and shell history as well as code. Review workflow output and scripts for accidental disclosure.
Respond to a suspected exposure
- Revoke the exposed credential immediately; do not rely on deleting the file or commit.
- Rotate or replace it, then update the systems and workflows that legitimately need it.
- Check repository history, build logs, and relevant access records for evidence of use or copying.
- Remove the exposed value from tracked files and prevent it from being reintroduced. Use secret scanning to help find other exposed credentials.
How do you stop a build workflow from becoming an entry point?
CI/CD workflows can access source, dependencies, and deployment credentials, so treat them as privileged systems rather than passive automation. A workflow triggered by untrusted code can become a path to secrets or other internal resources if it runs with excessive permissions.
Rank #2
- Transfer speeds up to 10x faster than standard USB 2.0 drives (4MB/s); up to 130MB/s read speed; USB 3.0 port required. Based on internal testing; performance may be lower depending upon host device. 1MB=1,000,000 bytes
- Backward compatible with USB 2.0
- Secure file encryption and password protection(2)
NIST Special Publication 800-204D, published in February 2024, recommends either running untrusted workflows in sandboxes without network access, privileged access, or the ability to read secrets, or delaying their execution until a maintainer with write access approves the run. Apply that principle to pull requests and other contributions that have not yet been trusted: isolate the run or require approval before it receives sensitive access.
- Keep workflow permissions limited to what the job needs.
- Do not expose deployment or publishing credentials to untrusted contributions.
- Require maintainer approval where a workflow cannot safely run without sensitive permissions.
- Review changes to workflow files as carefully as changes to application code.
How should code changes be reviewed and verified?
Require peer review before merging changes, especially changes to authentication, access policies, build workflows, deployment settings, and dependency declarations. Review should verify not only that code behaves as intended, but also that a change does not quietly introduce a credential, weaken a control, or redirect a build or release.
Rank #3
- USB-C 2-in-1 storage OTG: The Lexar JumpDrive Dual Drive D40E features USB Type-A and Type-C connectors in a slim, portable form factor for easy device compatibility
- Transfer speeds up to 100MB/s: Based on internal testing, performance may vary depending upon the host device, interface, and usage conditions. 1MB=1,000,000 bytes
- Plug and Play: Widely compatible with USB Type-C smartphones, tablets, laptops, Macs, and traditional Type-A devices, no software installation required. The 360° swivel design allows for easy switching between connectors without the hassle of losing a cap
- Durable & Compact: The Lexar D40E USB memory stick features a metal enclosure, withstands temperatures from 0° to 50° C (32°F to 122°F), and is lightweight at 26g with dimensions of 70.4 x 16.9 x 11.7mm
- Security & Warranty: Securely protects files using an advanced security software solution with 256-bit AES encryption. Backed by a Lexar 3-year limited warranty
OWASP identifies dependency confusion, upstream compromise, code-signing-certificate theft, and CI/CD exploits among software-supply-chain threats. Its guidance recommends documented peer review, strong access control, and monitoring. Those controls complement one another: review can catch suspicious changes, access limits reduce who can make them, and monitoring can help reveal activity that review misses.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do you manage and scan dependencies?
Third-party packages bring code from outside your repository into your software. Use an approved intake process rather than letting builds fetch arbitrary packages without oversight. CISA recommends IAM-integrated package repositories and policies that prevent packages from bypassing approved intake; its examples include GitHub Packages, JFrog Artifactory, and Sonatype Nexus Repository.
Rank #4
- Reliable storage for photos, videos, music and other files
- Available in capacities from 8GB to 256GB (1GB = 1,000,000,000 bytes - Actual user storage less)
- Transfer with confidence when moving images and other content
- Retractable design keeps the connector safe
- SanDisk SecureAcces software with 128-bit AES encryption and password protection(1)
- Use an internal package repository integrated with identity and access management where practical.
- Define which packages and sources are approved, and make the build process follow that policy.
- Use software-composition analysis to identify components and assess dependency vulnerabilities. NIST recommends this analysis and secure acquisition channels for open-source components.
- Run dependency-vulnerability management, secret scanning, and code scanning continuously. GitHub recommends these practices and documents exporting a repository dependency graph as an SPDX-compatible software bill of materials (SBOM).
Scanning helps identify issues; it does not establish that every dependency is safe or replace review of how a component is acquired and used.
How will you detect tampering and recover?
Enable audit logs and monitor repository and workflow activity. OWASP recommends logging and monitoring for version-control systems alongside strong access control. Use available records to investigate unexpected permission changes, unusual code or workflow modifications, and suspicious access or build activity.
Plan for recovery before an incident. Keep source and configuration under version control, know who can disable compromised access, and document how to revoke and replace exposed credentials. When investigating a suspected compromise, preserve relevant audit and build records, identify affected repositories and workflows, remove unauthorized access, and review changes before resuming releases. Monitoring and backups are useful only if someone knows what to check and how to act on it.
Quick Recap
What a practical source-code security baseline includes
- Private, centrally managed repositories with named identities and least-privilege permissions.
- Regular access reviews and prompt removal of departing users.
- Peer review and protection for sensitive workflow, deployment, and policy files.
- External, scoped secret storage; short-lived credentials where possible; and a clear revocation and rotation response.
- Sandboxing or maintainer approval for untrusted CI/CD workflows, without unnecessary network, privileged, or secret access.
- Approved dependency intake, software-composition analysis, secret and code scanning, and vulnerability management.
- Audit logging and monitoring paired with a defined investigation and recovery process.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
