← VCE Software Development U4O2

Securing a code repository

Controlling who can read and change a code repository and protecting what is stored in it, e.g. private repos, roles, a protected main branch, no secrets in commits, audit logs.

Understanding Securing a code repository in VCE Software Development U4O2

What it does: Different roles (Read, Write, Admin) limit who can view, change or manage the repository, following least privilege. Adding the .env file to .gitignore stops API keys and passwords from being committed and stored in the repository. A private repository can only be viewed by people who have been given access. A public one can be read by anyone on the internet. Branch protection means changes to main must be reviewed and approved first. This stops untested or malicious code going live unchecked. Version control keeps old commits, so a secret can still be found in the history. The password must be revoked and replaced, and secrets should be stored outside the code.

Common mistakes: The .env file holds secrets and must never be staged. Line 2 should stage .gitignore (git add .gitignore) so the secrets file stays out of commits. Turning review off lets changes be merged without a second person checking them. It should be require_review: true.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

This module's key terms are also in a printable crossword (Modules 49–72) and word search (Modules 49–130).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which repository setting best limits who can read the source code of a commercial app?
Make the repository publicMake the repository private
Matches
Repository visibility: Public (internal payroll app)
↓
A public repository lets anyone on the internet read the source code. Internal software should be set to private so only approved people can access it.
Applying
Meanings
Term
repository security
Meaning
Controlling who can read and change a code repository and protecting what is stored in it, e.g. private repos, roles, a protected main branch, no secrets in commits, audit logs.
Practice
SET visibility <- "private"
Testing
Gaps
repo.visibility = ""
Check Answer
Spots
1echo .env >> .gitignore
2git add .env

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Stag' badge — Forest Legend, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Quick Questions

1. Which repository setting best limits who can read the source code of a commercial app?
A. Make the repository public
B. Make the repository private ✓
A private repository can only be viewed by people who have been given access. A public one can be read by anyone on the internet.
2. A new intern needs to read code but should not change it. What role fits best under role-based permissions?
A. Read-only access ✓
B. Admin access
Role-based permissions give each person only what their job needs, which applies the principle of least privilege. Admin access lets someone change settings and delete the repository.
3. What does a protected main branch do?
A. Blocks direct pushes and requires a reviewed pull request ✓
B. Lets any developer push changes straight to main
Branch protection means changes to main must be reviewed and approved first. This stops untested or malicious code going live unchecked.
4. A developer commits a file containing a database password. Which statement is correct?
A. Deleting the file in the next commit makes the secret safe again
B. The secret is exposed in the commit history, so it must be removed and changed ✓
Version control keeps old commits, so a secret can still be found in the history. The password must be revoked and replaced, and secrets should be stored outside the code.
5. Which is a secure way to handle an API key for a project in a repository?
A. Store it in a secrets manager or environment variable outside the repo ✓
B. Hard-code it in config.js and commit the file
Keeping secrets out of commits stops anyone with repository access from reading them. Hard-coded keys are copied into every clone and every version of the history.

Match the Pairs

git push origin main (blocked by branch protection) → A protected main branch rejects direct pushes, so changes must go through a reviewed pull request
git log --format='%h %an %ad %s' → Shows an audit trail of changes: who made each commit, when, and what the change was
Role-based permissions give each person only the repository access their job needs → alice: Read bob: Write carol: Admin
Keep secrets out of commits so they are not stored in the repository history → echo ".env" >> .gitignore
Repository visibility: Public (internal payroll app) → A public repository lets anyone on the internet read the source code. Internal software should be set to private so only approved people can access it.
git commit -m "add db" # DB_PASSWORD = "admin123" in config.py → A password is hard-coded in a committed file. It stays in the history even if deleted later, so secrets should be kept outside the repository and the exposed password changed.

Key Term

repository security
Controlling who can read and change a code repository and protecting what is stored in it, e.g. private repos, roles, a protected main branch, no secrets in commits, audit logs.

Fill in the Blanks

1. repo.visibility = "private"
Hint: Type the visibility setting that hides the repository from the public and lets only approved people see it.
2. git log --author="sam" --oneline
Hint: Type the Git command that lists the history of commits, which forms an audit trail of who changed what.
3. branch: main protected: true reviews: 1
Hint: Type the setting name that stops people pushing straight to the main branch without a review.
4. repo.grant("intern", "read")
Hint: Type the lowest permission level, which lets a user view the code but not change it (least privilege).
5. echo ".env" >> .gitignore
Hint: Type the name of the file that tells Git which files to leave out of commits so secrets are not stored.

Spot the Error

Question 1
A echo .env >> .gitignore
B git add .env
C git commit -m 'Ignore env'
Line B — The .env file holds secrets and must never be staged. Line 2 should stage .gitignore (git add .gitignore) so the secrets file stays out of commits.
Question 2
A name: payroll-app
B visibility: private
C require_review: false
Line C — Turning review off lets changes be merged without a second person checking them. It should be require_review: true.
Question 3
A user: intern_sam
B role: read
C can_push_main: true
Line C — A read-only role should not be able to push to main. This breaks role-based permissions and least privilege. It should be can_push_main: false.
Question 4
A audit_log: on
B log_events: push, merge
C retain_days: 0
Line C — Keeping logs for 0 days means the audit trail of changes is deleted straight away. Logs should be kept for a sensible period, such as retain_days: 365.
Question 5
A git checkout -b fix-login
B git add login.py
C git commit -m 'Fix login'
D git push origin main
E # then open a pull request
Line D — The main branch is protected, so changes must go to a feature branch and be reviewed through a pull request. Line 4 should push fix-login, not main.

Student with a class code? Join your class →