Offensive SecurityOffensive SecurityOffensive Security

Examples of everyday tasks

• Agree on scope and rules of engagement before any testing starts.
• Map an application or network to understand where it could be attacked.
• Test for weaknesses and confirm their impact without causing damage.
• Chain small findings together to show a realistic attack path.
• Write findings with reproducible steps, evidence, and remediation advice.

Related job titles

• Penetration tester
• Red team operator

These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.

Starter project

Test a Vulnerable Practice App

Use an intentionally vulnerable application in an authorized local lab. Investigate a small number of weaknesses and explain their impact.

Never test a website or network you do not own or have written permission to test, even if it looks similar to your practice app.

What you’ll use

• An intentionally vulnerable web application running on your own computer or in a virtual machine, such as OWASP Juice Shop
• A web browser and its developer tools, plus a free intercepting proxy such as ZAP if you want to inspect requests
• A document for evidence and notes

Resources to start with

• OWASP Juice Shop (opens in a new tab)

  A free, intentionally insecure web application built for security training.

• ZAP (opens in a new tab)

  A free, open-source tool for inspecting and testing web application traffic.

More projects for this path

Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.

• Vulnerable App Test Report

  Test a deliberately vulnerable app in your own lab and report three findings properly.

• Authorized Web Recon Methodology

  Write and follow a repeatable recon process against your own lab application.

• API Authorization Lab

  Test an API you built for object and function level authorization flaws.

Project walkthrough

1. Install the practice app locally and write a short scope: which app, which address, and what is off limits. Only test systems you own or are explicitly allowed to test.
2. Use the app as a normal visitor and note the features that accept input, handle sign-ins, or show private data.
3. Choose two or three weaknesses to investigate instead of trying everything.
4. For each weakness, record the exact steps to reproduce it, with screenshots.
5. Explain the impact: what an attacker could do and who would be affected.
6. Recommend a fix for each finding, citing published guidance where you can.

What to publish

• A penetration-test report that states the scope and your testing approach
• Reproducible steps for each finding
• Evidence such as screenshots or captured requests
• The impact of each finding and remediation advice
• A statement that testing took place in an authorized local lab

Optional extension

Apply a fix where possible and document a retest.

Example résumé bullet

Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.

Numbers to record while you work

Project name | tools, datasets and frameworks | link

Give the project a name of its own: “Trapdoor” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.

Turn your project into a portfolio piece

A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.

Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.

Include:

1. Goal: What question or problem did you investigate?
2. Environment: What tools, practice data, or systems did you use?
3. Your work: What did you personally do, and why?
4. Evidence: Include useful screenshots, queries, code, or test results.
5. Findings: What did you discover? What remains uncertain?
6. Fix or recommendation: What should change, and did you test it?
7. Sources and limitations: Credit datasets and guides. Clearly identify simulated work.

Use sample or redacted information in the public version.

Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.

Put numbers in it

Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.

Name it, then show your tools

A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.

Project name | tools, datasets and frameworks | link

• Role-Based Access Lab→Turnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
• Login Hunt→Beacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
• Cloud Project→Bedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub

Why link a report?

Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.

Not every recruiter will open it, but it makes your work available for review.

Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.

# Project title

> Practice project. Describe the simulated scenario, practice data, or lab used.

## Goal
What question or problem did you investigate?

## Environment
What tools, practice data, or systems did you use? Link datasets and guides.

## My work
What did you personally do, and why?

## Evidence
Screenshots, queries, code, or test results. Use sample or redacted information only.

## Findings
What did you discover?
The numbers behind it (records searched, findings confirmed, tests added).
What remains uncertain?

## Fix or recommendation
What should change, and did you test it?

## Sources and limitations
- Datasets and guides used:
- What was simulated:
- Limitations:

Related paths to explore

• Application / Product Security

  Application and product security engineers work with software developers to design, build, and test features so they are hard to abuse.

• Network Security

  Network security analysts and engineers design and monitor the connections between devices so attacks are harder to launch and harder to spread.

• Cloud Security

  Cloud security analysts and engineers make sure services running on platforms such as AWS, Microsoft Azure, and Google Cloud are configured safely, monitored, and kept that way.