My progress
Menu

Cybersecurity Specialist · Focus area 1: Assessing your own systems

CY2: Authorised assessment: settings, packages and reports

Goal: plan an assessment within a written scope, review a system's settings and packages for known weaknesses, check the security headers it sends, rate each finding's severity with reasons, and write a report that gets problems fixed.

You'll need: Module 80 (Security Assessment), Module 78 (Secure Development), Module 75 (Web App Security), Module 63 (Introduction to Linux), and the AarogyaDesk practice kit (data/assessment-target/, assess/, docs/FORMATS.md).

Where this is used: yearly security reviews, customer security questionnaires, checks before a release, cloud configuration audits, and the weekly "which of our packages have new advisories?" job that most engineering teams run.

How it differs: a developer reads settings to make things work. An assessor reads the same settings asking what each one exposes, proves every finding with evidence, and writes it up so someone else can fix it without guessing.

Time: reading about 2½ hours · practice (the Try it tasks) about 2½ hours · assignment about 4 hours.

Lessons

  1. 1Planning an assessmentReading 15–25 minutes, plus practice✓
  2. 2Reviewing settingsReading 15–25 minutes, plus practice✓
  3. 3Reviewing packages and advisoriesReading 15–25 minutes, plus practice✓
  4. 4Headers and severityReading 15–25 minutes, plus practice✓
  5. 5Writing a report that gets things fixedReading 15–25 minutes, plus practice✓

🛠️Assignment: Assess the old AarogyaDesk server

  1. Write a half-page plan for the three checks, naming the baseline and the evidence for each.
  2. Review data/assessment-target/settings.json by hand and list each finding with its rule ID from docs/FORMATS.md.
  3. Match dependencies.json against advisories.json by hand, comparing versions as numbers. Note any version that text comparison would get wrong.
  4. Check response-headers.json against the five header checks.
  5. Write a one-page report: summary, findings ordered by severity, and limits.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How would you assess an old server's snapshot so the owner can trust and act on the result?

Show a good answer

A good answer mentions: confirming written permission and scope; planning checks from a standard list; reviewing settings such as debug, secrets, cookie flags, session length and CORS; matching installed versions to advisories by comparing numbers; checking security headers without regard to letter case; rating severity with a written guide and context; and a report with evidence, fixes, a plain summary, limits and a retest.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A manager asks for "a pen test" of the clinic app, but only wants its settings and packages checked against known problems. What's the accurate name?

Why each option is right or wrong

  • “A penetration test, since any security check can be called one” (Incorrect): A penetration test is a different, deeper method.
  • “An audit, since every review of settings is called an audit” (Incorrect): An audit checks controls against a standard.
  • “A bug bounty, since outside people will be checking the app” (Incorrect): Nobody outside is involved here.
  • “A configuration and dependency review, since that's what will be done” is correct.

    Naming the method accurately sets the right expectations.

    • Also: say what isn't included.

📖 Revise: Lesson 1: Planning an assessment

Question ID sp-cybersecurity-02-q1 · Report a mistake in this question
2. Two assessors review the same site. One writes "looks secure"; the other lists 30 checks with evidence. Why is the second more useful?

Why each option is right or wrong

  • “It's longer, and longer reports are taken more seriously by owners” (Incorrect): Length isn't the point.
  • “It used a more expensive tool, so its results are more reliable” (Incorrect): The tool isn't what makes it useful.
  • “It avoids naming problems, which keeps the owner calm and cooperative” (Incorrect): It names them clearly.
  • “Anyone can check what was looked at, what passed and what failed” is correct.

    Evidence and a checklist make a result repeatable.

    • Next: the owner can track each failed check.

📖 Revise: Lesson 1: Planning an assessment

Question ID sp-cybersecurity-02-q2 · Report a mistake in this question
3. A leaked API key is moved from a settings file into an environment variable. What's still wrong?

Why each option is right or wrong

  • “Nothing, since environment variables can't be read by anyone else” (Incorrect): The problem is that the key was already exposed.
  • “The variable name must be in capital letters to be secure” (Incorrect): Names don't affect security.
  • “Environment variables are slower, so the app will run badly” (Incorrect): Speed isn't the issue.
  • “The old key was exposed, so it must be replaced with a new one” is correct.

    Copies and history still hold the old key.

    • Then: check logs for use of the old key.

📖 Revise: Lesson 2: Reviewing settings

Question ID sp-cybersecurity-02-q3 · Report a mistake in this question
4. A settings file has "cors_allow_origins": ["*"] for a staff API. What does that allow?

Why each option is right or wrong

  • “Every staff member to log in without a password, from any computer at all” (Incorrect): CORS doesn't affect login.
  • “The API to call any website it likes on the internet” (Incorrect): CORS controls which sites may call it, not the reverse.
  • “Anyone to change the server's settings from the browser” (Incorrect): CORS doesn't expose settings.
  • “Scripts on any website to call the API from a logged-in user's browser” is correct.

    List only the clinic's own sites.

    • Rule: CFG-CORS in the kit.

📖 Revise: Lesson 2: Reviewing settings

Question ID sp-cybersecurity-02-q4 · Report a mistake in this question
5. A script compares versions as text and reports 2.10.0 as inside the range <2.9.0. What's the right conclusion?

Why each option is right or wrong

  • “The script is right, since 2.10.0 comes first when sorted as text” (Incorrect): Sorting text isn't how versions are ordered.
  • “The advisory is wrong, since ranges can't include two-digit numbers” (Incorrect): They can.
  • “Both are right, since 2.10 and 2.9 are the same version written differently” (Incorrect): They're different versions.
  • “The script is wrong: 2.10.0 is newer than 2.9.0 when compared as numbers” is correct.

    Text compares character by character.

    • Fix: split on dots and compare integers.

📖 Revise: Lesson 3: Reviewing packages and advisories

Question ID sp-cybersecurity-02-q5 · Report a mistake in this question
6. An advisory affects practice-mail <1.2.0, but the server doesn't have practice-mail installed. What goes in the report?

Why each option is right or wrong

  • “A high finding, since any advisory in the list must be reported” (Incorrect): Only installed packages matter.
  • “A finding for every package with a similar name to be safe” (Incorrect): That adds noise without evidence.
  • “A note to install practice-mail 1.2.0 so the server is up to date” (Incorrect): Installing unused packages adds surface.
  • “No finding, since that package isn't part of the system” is correct.

    Advisories apply only to what is installed.

    • Still: include indirect dependencies.

📖 Revise: Lesson 3: Reviewing packages and advisories

Question ID sp-cybersecurity-02-q6 · Report a mistake in this question
7. A header check reports CSP missing, but the server sends content-security-policy in lower case. What's wrong?

Why each option is right or wrong

  • “The server is wrong, since header names must be in title case” (Incorrect): Header names aren't case-sensitive.
  • “Both are fine, since the browser ignores lower-case headers” (Incorrect): Browsers accept any case.
  • “Neither, since a CSP header only takes effect when the server sends it twice” (Incorrect): One header is enough.
  • “The check is wrong, since header names should be compared ignoring case” is correct.

    Lower-case the names before checking.

    • Test 6 in Project 1 checks this.

📖 Revise: Lesson 4: Headers and severity

Question ID sp-cybersecurity-02-q7 · Report a mistake in this question
8. A 9.1 flaw sits in an internal tool nobody outside can reach; a 7.5 on the public login page is on a list of flaws used in real attacks. What's a sensible order?

Why each option is right or wrong

  • “The 9.1 first, since priority follows the score and nothing else” (Incorrect): Exposure and real-world use matter too.
  • “Both at once, since splitting the team is fastest” (Incorrect): Splitting can delay both.
  • “Neither, since scores below 10 can wait for the next release” (Incorrect): Both need fixing.
  • “The 7.5 first, since it's exposed and known to be used in attacks” is correct.

    Context raises its priority.

    • Then: schedule the 9.1 soon after.

📖 Revise: Lesson 4: Headers and severity

Question ID sp-cybersecurity-02-q8 · Report a mistake in this question
9. A report says "Server bad, fix soon." What should be added first?

Why each option is right or wrong

  • “More pages of tool output, to show how much work was done” (Incorrect): Raw output buries the finding.
  • “A score of 10, to make sure the owner reads it quickly” (Incorrect): The severity must match the evidence.
  • “The assessor's opinion of the developers who built the server” (Incorrect): Reports describe problems, not people.
  • “Evidence of the specific problem, its severity and the exact fix” is correct.

    Someone else must be able to check and act on it.

    • Plus: the impact in plain words.

📖 Revise: Lesson 5: Writing a report that gets things fixed

Question ID sp-cybersecurity-02-q9 · Report a mistake in this question
10. A finished report includes a real staff password the assessor noticed. What should happen?

Why each option is right or wrong

  • “Keep it in, so the owner knows exactly which password was weak” (Incorrect): Repeating the password exposes it further.
  • “Send it to more people, so the password is changed faster” (Incorrect): Wider sharing is the opposite of safe.
  • “Encrypt the report and keep the password in its title, so it isn't lost” (Incorrect): Titles are often shown unencrypted.
  • “Remove it, describe the problem without it, and ask for it to be changed” is correct.

    Reports shouldn't carry secrets or personal data.

    • Send: only to agreed people, by a secure route.

📖 Revise: Lesson 5: Writing a report that gets things fixed

Question ID sp-cybersecurity-02-q10 · Report a mistake in this question

ProLearners Assist