Contribute to an open-source cloud security tool

An open-source PR — even a small one — is a portfolio piece that signals: you can read other people's code, follow a contribution guide, work with maintainers, and ship. These are exactly the soft skills hiring managers can't test for in an interview. One merged PR to a recognized cloud security tool is worth multiple solo projects.

What you'll have at the end

• A merged PR (or, at minimum, an open PR with constructive maintainer dialogue) on a cloud security OSS project.
• A write-up describing the issue, your approach, what changed, and what you learned about the project's codebase.
• Bonus: a follow-up PR that addresses something you noticed while doing the first one.

Prerequisites

• A GitHub account.
• Comfort with git (branch, commit, push, rebase).
• Familiarity with the language the project uses (Python for most cloud security OSS).
• Patience — first PRs sometimes take days to get reviewed.

Step-by-step

1. Pick a project where you'd want to use the output

Some excellent on-ramps:

• Prowler — Python; ~400 checks; large issue backlog; very welcoming maintainers.
• Cloud Custodian — Python; YAML-policy engine; lots of "new policy" issues open.
• Pacu — Python; AWS exploitation framework; modules are self-contained and approachable.
• ROADtools — Python; Entra ID recon; smaller community, individual maintainer, replies fast.
• KICS — Go; IaC scanning; well-documented contribution guide; lots of "add a query" issues.
• Steampipe — Go; SQL across cloud APIs; many small plugin improvements available.

2. Read CONTRIBUTING.md and the recent merged PRs

Before writing code, read the contribution guide. Then read the last 10 merged PRs to absorb the project's tone, what "good" looks like, and any unwritten conventions. This step alone separates accepted PRs from rejected ones.

3. Find a 'good first issue'

Filter issues by the good first issue label. Pick one that's been open for a while (so it's truly available) but isn't ancient (which often means abandoned for a reason).

4. Comment on the issue first

"I'd like to take this on — does the approach of X sound right?" gets you maintainer signal before you've written code. Two-line comment, huge value.

5. Set up the dev environment

Clone the repo, install dev dependencies, run the test suite locally. If the test suite doesn't pass before you've changed anything, fix that first or pick a different project. (You'd be surprised.)

6. Implement the change

Small. Focused. Match the existing code style. Add tests if the project has them. Update docs if behavior changes.

7. Open the PR

Title: imperative, scoped ("Fix typo in S3 check description"). Body: link the issue, describe what changed and why, screenshots if visual, test output if not.

8. Iterate on review feedback

Maintainers will ask for changes. Address them quickly. "Done in [commit]" is a perfectly fine reply. Don't argue — they know the codebase better than you do.

9. Write up the experience

After merge: blog post or LinkedIn write-up. What did the codebase teach you? What was the contribution flow like? What would you contribute next? This is the artifact that persists.

10. Plan a follow-up

The hardest PR is the first one. The second is much easier. Pick a related issue and queue another. Two merged PRs to the same project signals durable engagement, not a one-off.

What hiring managers look for

• The PR was actually merged (or has a clear path to merge). Open-but-stale PRs read as unfinished.
• Your write-up reflects on the codebase you read, not just the lines you wrote. "Reading other people's code" is what staff engineers spend most of their time doing.
• You followed the contribution guide. Maintainer dialogue in the PR thread shows up.
• You can talk about why you chose this project and what you'd contribute next.
• You picked a project the hiring company might also use. Bonus signal: "I shipped a fix to the tool you're using" is a memorable interview moment.

Common mistakes

• Picking a giant feature for your first PR. Aim for one-file changes you can ship in an afternoon.
• Skipping CONTRIBUTING.md. Reviewers can tell.
• Working on something nobody filed an issue for. Some projects don't accept unsolicited features.
• Disappearing after submitting. PRs need active iteration; check daily for review comments.
• Letting a PR sit open for months with no response. Comment-bump politely once, then move on if it's not viable.
• Listing the PR on your resume but linking to a forked repo or your own branch instead of the upstream PR. Recruiters can't follow that.

Where to publish

The full publishing playbook is on the portfolio hub page. The short version: a public GitHub repo with a thorough README is the strongest single signal; pair it with a LinkedIn post and (optionally) a 5-minute lightning talk at a CSOH Friday Zoom.