Building a Portfolio: CTFs, Writeups and Public Code

When you apply for a first job in security, you face a classic problem: you need experience to get a job and a job to get experience. A portfolio breaks the circle. It shows what you can do, not just what you claim. Since the start of this course, you have been filling folders with artifacts; now you will learn how to organize, polish and publish them wisely, without crossing legal or ethical lines.

What recruiters look for

Hiring managers reading a junior profile usually want to see:

• Curiosity and persistence: you learn on your own and finish things.
• Practical skill: you have done real exercises, not just watched videos.
• Clear communication: you can explain technical topics simply, in writing.
• Professional ethics: you work legally, handle information responsibly and respect rules.
• Method: you follow a structured approach and document your work.

Quality beats quantity. Three excellent items are better than thirty unfinished ones.

The five kinds of portfolio items

1. Writeups of challenges and labs

A writeup explains how you solved a challenge: the goal, your approach, what you tried that failed, what worked and what you learned. Good writeups focus on the reasoning, not just the steps. They are a favorite of recruiters because they show how you think.

Mind the rules. Many platforms and competitions have policies about publishing solutions. Active challenges and ongoing competitions usually must not be spoiled; retired content may be allowed, while some platforms forbid public solutions altogether. Read the terms of each platform before you publish, and when in doubt, publish a general lessons-learned article instead of a step-by-step solution.

2. Capture-the-flag participation

CTF events build technical range and teamwork. Note your participation, your team, the categories you worked on and what you learned. Rankings are fine to mention, but the story of what you learned matters more.

3. Code and tools

The Python scripts from chapter 2 are perfect starting points: a scope checker, a log summarizer, a header auditor. Publish them in a public code repository with a clear README, with defensive or educational purpose and a license. Do not publish offensive tools that could be used directly against others without safeguards, and do not publish anything that contains real credentials or data.

4. Sample reports and documents

A sample vulnerability report (lesson 6.2), a sample pentest report for your own lab, a detection use case, an incident response plan or a hardening checklist show professional skills that many technical candidates lack. Make sure they use fictional or lab data only.

5. Learning in public

A short blog, notes or a technical diary demonstrate consistency. Posts like "What I learned building a log parser" or "How I explained Kerberoasting to a manager" help others and show your communication skills.

Structuring your portfolio

If you followed the portfolio steps of this course, you already have a folder per chapter. Here is a clean structure you can present:

portfolio/
  README.md                      overview, about me, ethics statement
  01-active-directory/           architecture diagram, attack path exercise, hardening checklist
  02-python-security/            scope_check.py, log_summary.py, header_audit.py
  03-red-blue/                   exercise plan, SOC playbook, purple session report, tabletop
  04-detection-response/         detection use cases, IOC vs TTP, coverage map, IR plan
  05-cloud-modern-apps/          cloud checklist, API review, container and pipeline guides
  06-bug-bounty-community/       policy checklist, sample report, certification plan
  writeups/                      CTF and lab writeups where allowed

In the top-level README.md, include: who you are and what you aim for, a short guide to the most representative three projects, and an ethics statement, for example: "All work was performed in my own lab or on legal training platforms. Nothing here targets real systems. Tools are for educational use on systems you own or are authorized to test."

A README template for each project

1. Title and one-line purpose.
2. Why I built it and what I learned.
3. How to run it, with example commands and expected output.
4. Safety and legal note.
5. Limits and possible improvements.
6. License.

Protecting yourself and others

• No real data. No real names, addresses, logs, credentials, internal documents or client information. Replace with fictional equivalents.
• No confidential work. If you worked for a client or employer, you need their permission to share anything. Describe skills in general terms instead.
• No active vulnerability details. Never publish details of an unfixed vulnerability in a real product. Follow coordinated disclosure.
• Scan before you publish. Check your repository history for accidentally committed secrets. Removing a file later does not remove it from history.
• Mind your digital footprint. A public portfolio is visible to employers, and also to attackers. Consider what personal information you reveal; apply the privacy principles from the first course in the track.
• Respect licenses and attribution. Credit sources, and do not copy others' writeups or text. Original wording is essential.

Writing a good writeup: a simple template

1. Context: platform and type of challenge (without breaking rules).
2. Goal: what you needed to find or achieve.
3. Method: your reasoning and decisions at each stage, including dead ends.
4. Key insight: the moment that unlocked the problem.
5. Defensive lesson: how this weakness would be prevented or detected in a real environment. This is what sets you apart.
6. Tools and references: official documentation and resources used.

The "defensive lesson" section links offense and defense, like the whole of this course.

Keeping momentum

• Publish small and often. One short, polished item every week or two builds a body of work.
• Review old work. Improve earlier items as your skills grow.
• Ask for feedback from mentors and community members, and respond kindly to criticism.
• Make it findable. Link your portfolio from your professional profile and your CV.
• Accept imperfection. A modest but honest portfolio is better than none.

Your turn: write a README

Write the README for your header_audit.py script from chapter 2, following the six-point template. Keep it under 200 words.

# header_audit

A small defensive script that checks which standard HTTP security
headers a web page sends.

## Why I built it
To practice writing safe, scoped tools in Python and to learn what
each header protects against.

## How to run it
    python3 header_audit.py http://localhost:3000
Prints which headers are present or missing and returns an exit code.

## Safety and legal note
The script refuses any host that is not in its allowed list. Use it
only on systems you own or are authorized to test, such as a local
training application. It sends a single request and exploits nothing.

## Limits and ideas
Missing headers are hygiene observations, not proof of vulnerability.
Ideas: cookie attribute checks, JSON output, configuration file.

## License
Open source license of your choice.

Portfolio step

Assemble the structure shown above in a single folder, write the top-level README.md with the ethics statement, choose your three best items and list them at the top. Run a final check: search every file for real names, real addresses, passwords, tokens and domain names that are not fictional. When you are ready, you can publish it in a public code repository. This is the main deliverable of the course. The final chapter will turn it into a career plan.

You are ready for the final chapter: turning skills into a career and an action plan.