Cybersecurity Portfolio: What to Put in It to Convince
Cybersecurity portfolio: which projects to choose for the role you want, how to document them, where to publish them and the mistakes that worry recruiters.
In cybersecurity, every recruiter or practitioner reading your application asks the same question: can this person really do what they claim? A well-built portfolio answers it before the interview even starts. Here is what it should contain for the role you are targeting, how to document each project, and the mistakes that turn good intentions into red flags.
What a cybersecurity portfolio is for
Your CV summarizes; your portfolio demonstrates. Your cybersecurity CV states your skills in a few lines; the portfolio shows how you think, how you work and how you write.
It is especially useful in three situations:
- You are starting out and have little or no professional security experience.
- You are changing careers and need to show your practice goes beyond the course you took.
- Your work is confidential and you can't show anything from past engagements.
For experienced professionals, a portfolio is still a plus, but it weighs less than experience. A few well-chosen pieces are enough.
Keep one idea in mind: a portfolio is not a showcase, it's a file of evidence. Three solid projects beat twenty abandoned repositories.
What a security portfolio can contain
There is no single format. A portfolio can be a personal site, a technical blog, a well-kept GitHub profile or a simple page gathering your links. What matters is the nature of what's in it.
| Type of item | What it proves | Example |
|---|---|---|
| Documented home lab | Ability to build, attack and defend an environment | Active Directory domain, SIEM and simulated attacks, with a build log |
| CTF or training machine write-ups | Method, persistence, ability to explain | Detailed solution including dead ends and a proposed fix |
| Detection rules | Understanding of attacks and telemetry | Sigma rules or SIEM queries with the scenario they cover |
| Scripts and tools | Automation, code quality | Log collection tool or analysis script, with documentation |
| Mock audit report | Writing, prioritization, client sense | Penetration test report on a deliberately vulnerable environment |
| Articles and talks | Teaching, curiosity, keeping up to date | Article on a technique, meetup talk |
| Open source contributions | Teamwork, code review | Fixes or new rules for a recognized security project |
You don't need all of them. Pick what serves the role you want.
Choosing projects for the role you want
A recruiter reads your portfolio through the lens of the role they are filling. What convinces for a pentest role won't necessarily convince for a GRC one.
SOC analyst or incident response
- A defensive home lab: Windows endpoints, log collection, a SIEM, a few replayed attacks and how you detected them.
- Commented detection rules, including the false positives you ran into.
- A full written investigation on a public dataset, with a timeline and conclusions.
Our path to becoming a SOC analyst explains how to build this kind of lab.
Pentest or red team
- Training machine write-ups that focus on methodology rather than a list of commands.
- A mock penetration test report written as if for a real client: executive summary, prioritized findings, recommendations.
- A small tool or script that saved you time, with documentation.
The report is often the missing piece, even though it is a large part of the job. Our guide to becoming a pentester covers this in more detail.
Application security and DevSecOps
- A code review of a deliberately vulnerable application, with proposed fixes.
- A CI pipeline that includes security checks, explained step by step.
- Open source contributions, even small ones.
If you come from development, our article on moving from development to application security offers more ideas.
Cloud security
- A test environment deployed with infrastructure as code, with the security controls you added and why.
- A configuration review of a test account, with the gaps you found and fixed.
GRC
A technical portfolio is less expected here, but still possible: a risk analysis of a fictional organization, a security policy written and annotated, or a briefing note on a regulation such as NIS2. The goal is to show you can structure and write.
Documenting a project: the method
A project without explanation proves very little. For each item, a short page is enough, built around five points.
- Context: what problem, what goal, in two or three sentences.
- Your approach: the choices you made, the alternatives you dropped and why.
- The result: what works, and what doesn't yet.
- The limits: what you would do differently in a real environment.
- What you learned.
Point 4 is the one that sets candidates apart. Showing that you see the gap between a lab and production (volume, business constraints, authorization) signals maturity.
Take care of the presentation too: a clear README at the root of each repository, readable code, and screenshots scrubbed of any real data.
Where to publish your portfolio
You don't need anything elaborate.
- GitHub or GitLab for code, detection rules and configurations, with your best repositories pinned.
- A blog or static site for write-ups, reports and articles.
- LinkedIn to share your publications and make the portfolio visible to recruiters.
Put a single link to your portfolio in your CV header. A reader should find your best work in under a minute.
Mistakes that hurt your application
A portfolio can also cost you points. These are the most common mistakes.
- Publishing confidential data: excerpts from client reports, screenshots from a former employer, real IP addresses. It's a deal breaker, because it shows exactly what an employer fears.
- Showing out-of-scope activity: everything you present must have been done on your own systems or on environments built for it.
- Breaking platform rules: some platforms forbid publishing solutions for challenges that are still active. Respect that.
- Copying without understanding: an unmodified fork or a copied write-up is quickly exposed in an interview.
- Leaving projects abandoned: ten empty repositories dilute your three good ones. Archive or hide the rest.
- Neglecting the writing: security work involves a lot of writing. Muddled text raises doubts about your future reports.
Preparing the interview from your portfolio
A good portfolio steers the interview onto your ground. Expect to be asked to walk through a project, and prepare for it.
- Pick one flagship project linked to the role and be able to present it in five minutes.
- Prepare your answer to "what didn't work?"
- Anticipate "how would you do this in production?"
- Reread everything that's online: every line can become a question.
If the process includes a technical exercise, our guide to preparing for a hands-on cybersecurity test completes this preparation. And if you play CTFs, see how to make them count on your CV.
Checklist before sharing your portfolio
- Three to five projects chosen for the target role, no more.
- Each project covers context, approach, result, limits and lessons learned.
- No real, confidential or former-employer data.
- Everything was done in an authorized environment.
- Abandoned projects are archived or hidden.
- A single link appears in the CV header and on LinkedIn.
- I can present my flagship project in five minutes.
In short
An effective cybersecurity portfolio is short, targeted and honest. It brings together a few projects chosen for the role you want, documents your approach as much as your results, and acknowledges its own limits. It often makes the difference for junior and career-change profiles, and it is a valuable support for everyone else.
At Cyber Recrut, we share this evidence-first approach: our shortlisted candidates prove their skills on hands-on labs close to the actual role, and your portfolio becomes a natural starting point for the conversation. Join the network for free and see how we work.