Building a Cyber Security Portfolio Employers Trust

Most security job candidates without experience have done real work in labs and challenges, but cannot show it in a form a hiring manager can check in five minutes. A portfolio closes that gap: a small set of write-ups, repositories and lab evidence that proves you can think, build and communicate like a practitioner. This guide covers what to include for each career track, how to structure a write-up and a repository so reviewers trust it, what to keep out for legal and ethical reasons, and how to use the portfolio in applications and interviews. It is for career changers, students, IT staff moving into security, and the hiring managers who review their work. Building the lab itself is covered in the Building a Cybersecurity Home Lab Guide, and the wider career map in the Cybersecurity Careers Guide.

Key takeaways

Quality over volume. Three to six finished, well-explained pieces beat thirty half-done repositories; GitHub lets you pin up to six items, so design for that.
Match the evidence to the role. A SOC analyst portfolio shows detections and investigations; a GRC portfolio shows risk registers and control mappings; an engineering portfolio shows automation and secure builds.
Explain the why, not just the how. Reviewers look for reasoning: what you were trying to find, what you tried, what failed and what you would change.
Stay legal and within platform rules. Only publish work on systems you own or are authorised to test, and only write up challenges the platform allows, such as retired content.
Treat the portfolio as a security artefact. No real secrets, no employer or client data, no personal data. A leaked key in a security candidate's repository is an instant rejection.

What employers actually check

Hiring managers rarely read a portfolio end to end. They sample it, usually in the minutes before or during a screening call, looking for a few signals:

Signal	What the reviewer looks at	What convinces them
Can you reason through a problem?	One write-up, read in full	Clear hypothesis, evidence, dead ends acknowledged, conclusion tied to evidence
Can you build something that works?	A pinned repository: README, structure, last commit	Runs from the README instructions, has tests or sample output, sensible commit history
Do you understand defence, not just tools?	Detection rules, hardening notes, lab design	Mapping to ATT&CK techniques, false-positive notes, explanation of trade-offs
Can you communicate?	Writing style across pieces	Short executive summary, plain language, correct terminology
Are you safe to hire?	Any sign of unauthorised testing, leaked data or secrets	Scope statements, sanitised screenshots, no credentials anywhere in history
Are you still learning?	Dates on pieces, recent activity	Steady activity over months rather than one burst

Portfolio contents by career track

Pick the track you are applying for and build mostly for it. One or two pieces from a neighbouring track show breadth.

Track	Strong portfolio pieces	Related guide
SOC and detection	Sigma rules with test data and ATT&CK mapping; an investigation write-up from a public log dataset or your own lab; a SIEM dashboard with explanation	SOC Analyst Career Guide
Incident response and forensics	Timeline reconstruction from a published practice image; a sample incident report with executive summary and evidence log	Cybersecurity Careers Guide
Penetration testing	Write-ups of retired challenges focused on root cause and remediation; a sample report for a deliberately vulnerable app you host yourself	Penetration Tester Career Guide
GRC and risk	Risk register and treatment plan for a fictional company; policy mapped to ISO/IEC 27001:2022 Annex A; supplier assessment questionnaire with scoring	GRC Analyst Career Guide
Cloud and security engineering	Infrastructure as code with security checks in the pipeline; a script that audits a test cloud account configuration; a hardening baseline with before and after evidence	Building a Cybersecurity Home Lab Guide
Bug bounty and vulnerability research	Publicly disclosed reports where the programme allowed disclosure; CVE credits; methodology notes without live targets	Bug Bounty Hunter Career

Public skill frameworks help you name what each piece demonstrates. The NIST NICE Workforce Framework for Cybersecurity gives a common language for cyber security work roles and the knowledge and skills they need; quoting the relevant work role in a piece's summary helps a recruiter match it to the job description.

Writing a write-up reviewers trust

A write-up is the best single piece of portfolio evidence because it shows thinking. Use a consistent structure:

Summary (three to five sentences): what the exercise was, what you found and the one lesson that matters. Many reviewers read only this.
Scope and authorisation: where the work was done (your lab, a retired platform challenge, a public dataset) and why you were allowed to do it.
Approach: your hypothesis and the order you worked in. Include dead ends: they show judgement.
Findings and evidence: sanitised screenshots, log extracts or queries that support each claim.
Defensive view: how a defender would detect, prevent or remediate what you found, with ATT&CK technique IDs where they fit, for example T1059.001 PowerShell or T1078 Valid Accounts.
What you would do differently: one or two honest lines.

Keep offensive detail proportionate. A hiring manager wants to see that you understood the weakness and its fix, not a copy-and-paste exploit chain. Write-ups that read as a defender's analysis of an attack are also safer to publish and more useful to the wider community.

Platform rules matter. Training platforms set their own publication rules. Hack The Box, for example, allows public write-ups only for retired machines, challenges and Sherlocks, Starting Point machines and Tier 0 Academy modules, and asks users to confirm retired status before posting; enterprise-exclusive content may not be shared publicly. Check each platform's rules before publishing and say in the write-up that the content is retired or permitted.

GitHub projects that read as professional work

A repository is judged in seconds from its landing page. Make those seconds count:

Profile README: GitHub shows a profile README from a public repository named exactly after your username with a README.md at its root. Use it for a three-line introduction, the track you are targeting and links to your best pieces.
Pinned items: pin up to six repositories or gists combined. Pin finished work only, ordered by relevance to the roles you want.
README per repository: purpose, how to run it, sample output, limitations and a licence statement. Without a licence, default copyright applies and others cannot legally reuse the code, so pick one deliberately.
Tests and checks: even a small test suite or a linter in a CI workflow shows engineering discipline. Contributing a rule to a community project such as SigmaHQ is strong evidence because it must pass the project's log source, rule structure and validation checks before review.
Commit history: meaningful commit messages over weeks look like real work; one giant commit looks copied.
Contributions to others' projects: documentation fixes, detection rules or bug reports to open source security tools show collaboration and are visible on your profile.

Secrets and data hygiene in public repositories

Security candidates are held to a higher standard. Before anything goes public:

Keep push protection on. GitHub enables push protection for users by default on personal accounts, blocking pushes of recognised secrets to public repositories. Do not bypass it for convenience.
Scan the full history, not just the current files, with a secret scanner before making a private repository public. A key removed in a later commit is still in history. See the Git Secret Scanning Guide.
Use placeholder values and environment variables in examples, and a .gitignore that excludes credential files, state files and lab exports.
Strip personal data, internal hostnames and IP addresses from logs and screenshots; use documentation ranges such as 192.0.2.0/24 for examples.
Rotate any lab credential that appears in a screenshot, even in an isolated lab.

Turning home lab work into evidence

A lab only becomes portfolio evidence when it is documented. For each lab project, publish:

A design note: a network diagram, the purpose of each machine and why you chose the isolation approach.
A build log: what you configured and in what order, as infrastructure as code where possible so a reviewer can see it is reproducible.
An exercise and result: for example, a simulated attack technique in your own lab, the telemetry it produced, the detection you wrote and how you tuned its false positives.
A measurement: detection coverage before and after, mean time to detect your own test, or the number of hardening findings closed.

The lab build itself, hardware and safe isolation are covered in the Building a Cybersecurity Home Lab Guide. For detection pieces, see the Sigma Rules Guide and the Detection Engineering Guide.

Legal and ethical boundaries

Authorisation: test only systems you own or have written permission to test. In the UK, section 1 of the Computer Misuse Act 1990 makes it an offence to cause a computer to perform a function with intent to secure unauthorised access, knowing it is unauthorised; other countries have similar laws. See the Computer Misuse and Anti-Hacking Laws Guide.
Bug bounty disclosure: publish a bug bounty finding only when the programme's disclosure policy allows it, usually after the fix and with the programme's agreement. See the Bug Bounty and Vulnerability Disclosure Guide.
Employer and client work: never publish it, even sanitised, without written permission. Describe it in your CV at the level of outcomes instead.
Third-party content: credit datasets, tools and other people's research; respect licences on intentionally vulnerable applications such as OWASP Juice Shop (MIT licence).
AI-generated work: if you used an AI assistant, say how. Reviewers probe in interviews, and work you cannot explain counts against you.

Choosing a format and platform

Format	Best for	Trade-offs
GitHub profile and repositories	Code, detection rules, infrastructure as code, tooling	Weak for long-form narrative; history is permanent
Personal site or blog	Write-ups, reports, an index of everything	Needs upkeep; a self-hosted site is itself evidence of how you secure things
Static site from a repository	Combining both with version history	Slightly more setup; content and code live together
PDF sample report	GRC and penetration testing roles, where reports are the product	Not searchable; keep it short and sanitised
Professional networking posts	Visibility and summaries linking back to full pieces	Poor as the only home: posts are hard to find later

Small budget or little time: a GitHub profile README plus three pinned pieces is enough. Targeting consultancy or GRC roles: add one polished sample report. Targeting engineering roles: prioritise repositories with tests and pipelines over prose.

Where identity fits

Identity skills are in demand and easy to evidence in a lab: an identity provider with MFA and conditional access policies, a privileged access tiering design, or a script that finds stale service accounts and unused API keys in a test tenant. Machine identities are a good differentiator because few entry-level candidates show them. See the GitHub Apps vs Personal Access Tokens vs OAuth Apps guide for a portfolio-friendly example of choosing the least-privileged credential for your own automation.

Using the portfolio in applications and interviews

Link selectively: on a CV, link the profile once and one or two pieces most relevant to that job, not a list of everything.
Tailor the pin order: before applying for a SOC role, pin detection work first; for GRC, pin the risk register.
Prepare a two-minute walk-through: for each pinned piece, be ready to explain the problem, your decisions and what you would change. Interviewers often pick one piece and dig.
Expect challenge: reviewers ask why you chose a detection logic or a risk rating. Be honest about limits. See the Cyber Security Interview Preparation Guide.
Refresh quarterly: archive outdated pieces, update READMEs and add one new piece each quarter.

Measuring whether your portfolio works

Screening conversion: share of applications that include the portfolio link and lead to a first interview.
Interview references: how often interviewers mention or ask about a specific piece.
Completion: number of finished pieces with summary, scope, evidence and defensive view (target three to six).
Hygiene: zero secrets or personal data found by a full-history scan before each public release.
Freshness: at least one new or updated piece per quarter.

Common failure patterns

Tutorial clones: repositories copied from courses with no changes or explanation. Reviewers recognise them; add your own extension and say what you changed.
Tool screenshots without reasoning: pages of tool output with no hypothesis or conclusion show tool use, not thinking.
Active challenge spoilers: publishing write-ups for live platform content breaks terms of service and signals poor judgement.
Secrets in history: API keys or lab passwords committed and later deleted, still visible in the commit log.
Unscoped testing: write-ups of probing real websites without authorisation. This can be a criminal offence and ends applications.
Abandoned breadth: twenty repositories with no README and a last commit two years ago suggest unfinished work.

Practitioner checklist

Choose a target track and list the three to six pieces that best evidence it.
Create a GitHub profile README and pin only finished, relevant work.
Use the same write-up structure for every piece: summary, scope, approach, evidence, defensive view, lessons.
Map detection and attack-related pieces to ATT&CK technique IDs.
Confirm every write-up is permitted by the platform or programme and say so in the piece.
Run a full-history secret scan and keep push protection on before publishing any repository.
Add a README and a deliberate licence choice to every public repository.
Document lab work with a design note, build log, exercise and measurement.
Prepare a two-minute explanation for each pinned piece.
Review and refresh the portfolio every quarter.

Building a Cyber Security Portfolio: Write Ups, GitHub Projects and Home Lab Evidence Employers Check