What makes a development environment insecure

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. Which development environment is MORE insecure?

A Every developer shares one admin login and can change any file

B Each developer has their own login with access only to the files they need

2. Which practice makes a development environment insecure?

A Developers only use libraries from an approved and checked list

B Developers install any library they find without checking it

3. True or false: A development environment is secure as long as the final software is tested before release.

A False - the environment itself must also be protected

B True - testing the final product is enough

4. Which source code setup is MORE insecure?

A Code stored in a public repository with no access restrictions

B Code stored in a private repository with restricted, logged access

5. Which situation shows 'no monitoring' in a development environment?

A Access logs are reviewed, so unusual changes to the code are spotted

B Nobody checks logs, so an attacker's changes to the code go unnoticed

Match the Pairs

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

Left column		Right column
1Shared admin login: dev_team / Password1 for all developers		AAn unmanaged tool and dependency: packages are added without vetting, so malicious or vulnerable code can enter the software
2npm install any-package --force (no version checks or approval)		Blogging = OFF; alerts = NONE; access_log_review = never
3Unprotected source code: a public repository with no access restrictions exposes code and secrets to attackers		CPermissions are too open, so any user or intruder can change the source code. It should follow least privilege with only the access each role needs.
4No monitoring: without logs or alerts, suspicious activity in the environment goes unnoticed		Dgit remote add origin https://public-repo.com/payroll-app (visibility: public, API key in config.js)
5chmod 777 /project/source (every user can read, edit and delete the code)		ETools are unmanaged, with no approved list, updates or tracking. Only approved, patched tools should be allowed and recorded.
6Developers install any free tool they like on the build server, and no one keeps a list		FA weak access control: everyone shares one easily guessed admin account, so actions can't be traced and attackers can gain full access

Definitions

insecure development environment

Fill in the Blanks

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

repo.visibility = "______"

GRANT ___ PRIVILEGES ON *.* TO 'dev';

IF library.version _ latest THEN FLAG library AS outdated

logging = _____ alerts = False

git add ____ git commit -m "update" git push origin main

Spot the Error

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

Question 1

A server.env = 'development'

B server.require_login = True

C server.allow_guest = True

Question 2

A role = user.role

B if role == 'developer':

C allow_admin(repo)

D else:

E deny(user)

Question 3

A pkgs = load('approved.txt')

B for p in requested:

C if p not in pkgs:

D install(p)

Question 4

A def login(user, pw):

B delete_log(user)

C if check(user, pw):

D return True

E return False

Question 5

A repo.visibility = 'public'

B repo.branch_protect = True

C repo.require_review = True

Answer Key

What makes a development environment insecure

Section A: Quick Questions

A — Every developer shares one admin login and can change any file

B — Developers install any library they find without checking it

A — False - the environment itself must also be protected

A — Code stored in a public repository with no access restrictions

B — Nobody checks logs, so an attacker's changes to the code go unnoticed

Section B: Match the Pairs

Shared admin login: dev_team / Password1 for all developers → A weak access control: everyone shares one easily guessed admin account, so actions can't be traced and attackers can gain full access

npm install any-package --force (no version checks or approval) → An unmanaged tool and dependency: packages are added without vetting, so malicious or vulnerable code can enter the software

Unprotected source code: a public repository with no access restrictions exposes code and secrets to attackers → git remote add origin https://public-repo.com/payroll-app (visibility: public, API key in config.js)

No monitoring: without logs or alerts, suspicious activity in the environment goes unnoticed → logging = OFF; alerts = NONE; access_log_review = never

chmod 777 /project/source (every user can read, edit and delete the code) → Permissions are too open, so any user or intruder can change the source code. It should follow least privilege with only the access each role needs.

Developers install any free tool they like on the build server, and no one keeps a list → Tools are unmanaged, with no approved list, updates or tracking. Only approved, patched tools should be allowed and recorded.

Section C: Definitions

insecure development environment — A workspace where weak controls over people, tools, code and data let vulnerabilities enter the software or let attackers reach it.

Section D: Fill in the Blanks

repo.visibility = "public"

GRANT ALL PRIVILEGES ON *.* TO 'dev';

IF library.version < latest THEN
  FLAG library AS outdated

logging = False
alerts = False

git add .env
git commit -m "update"
git push origin main

Section E: Spot the Error

C — Allowing guest access to the development server is a weak access control, because anyone can reach the code and data without logging in. It should be server.allow_guest = False.

C — Giving every developer admin rights breaks the principle of least privilege and is a weak access control. A developer should only get the access they need, such as allow_read(repo).

D — A package that is not on the approved list should be blocked. Installing it adds an unmanaged dependency that could be malicious or vulnerable. The line should be block(p).

B — Deleting the log means login attempts are not monitored, so attacks go unnoticed. The line should record the attempt with log_attempt(user).

A — A public repository leaves the source code unprotected, so anyone can read it and look for vulnerabilities or secrets. It should be set to 'private'.