Securing a code repository

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

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

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

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

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

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1git push origin main (blocked by branch protection)		AA 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.
2git log --format='%h %an %ad %s'		Balice: Read bob: Write carol: Admin
3Role-based permissions give each person only the repository access their job needs		CA 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.
4Keep secrets out of commits so they are not stored in the repository history		DShows an audit trail of changes: who made each commit, when, and what the change was
5Repository visibility: Public (internal payroll app)		EA protected main branch rejects direct pushes, so changes must go through a reviewed pull request
6git commit -m "add db" # DB_PASSWORD = "admin123" in config.py		Fecho ".env" >> .gitignore

Definitions

repository security

Fill in the Blanks

Complete each line of code by filling in the missing parts.

repo.visibility = "_______"

git ___ --author="sam" --oneline

branch: main _________: true reviews: 1

repo.grant("intern", "____")

echo ".env" >> __________

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A echo .env >> .gitignore

B git add .env

C git commit -m 'Ignore env'

Question 2

A name: payroll-app

B visibility: private

C require_review: false

Question 3

A user: intern_sam

B role: read

C can_push_main: true

Question 4

A audit_log: on

B log_events: push, merge

C retain_days: 0

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

Answer Key

Securing a code repository

Section A: Quick Questions

B — Make the repository private

A — Read-only access

A — Blocks direct pushes and requires a reviewed pull request

B — The secret is exposed in the commit history, so it must be removed and changed

A — Store it in a secrets manager or environment variable outside the repo

Section B: 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.

Section C: Definitions

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.

Section D: Fill in the Blanks

repo.visibility = "private"

git log --author="sam" --oneline

branch: main
protected: true
reviews: 1

repo.grant("intern", "read")

echo ".env" >> .gitignore

Section E: Spot the Error

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.

C — Turning review off lets changes be merged without a second person checking them. It should be require_review: true.

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.

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.

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.