Application / Cybersecurity Engineer

Tell us how you build.

Short, specific answers beat long ones. Your draft is kept in this browser until you submit.

01 About you

Full name

Location and timezone

Hours per week you can give

GitHub or portfolio

LinkedIn optional

This is a paid role, but the budget is still being negotiated, so we cannot give you a number yet. Does that work for you?

Yes, I can start before the budget is set I need the number before I start Contact me once the budget is set

02 Your experience

What is your stack?

AWS security services, IaC scanners (Checkov, tfsec, Trivy, Prowler), SAST, threat modeling, incident response, languages. Mark what you have used in production.

How well do you know AWS IAM policy evaluation?

Describe one security control or detection you built and kept running.

What did it catch, how did you measure false positives, and what broke first?

03 How you would work here

A pull request changes an IAM policy from s3:GetObject on one bucket to s3:* on arn:aws:s3:::*, with a condition on aws:SourceVpc. What severity should the analyzer assign, and what facts must the finding contain?

The explanation layer may only say what the facts prove.

Our Action runs on pull_request_target so it can comment on pull requests from forks. It checks out the pull-request head and runs terraform plan. What is the risk, and how would you redesign the workflow?

Name the attack and the permissions involved.

A security group rule allows TCP/22 from 0.0.0.0/0. The instance it is attached to is in a private subnet with no route to an internet gateway. What should the analyzer report?

Nothing, because the instance is not reachable A high-severity finding saying the internet can reach SSH A finding for the permissive rule, with the routing recorded as a fact and no claim of internet exposure Ask the model whether the instance is reachable

04 Design problem

Wayne Citadel runs in a customer's GitHub Actions. It reads plans from pull requests that anyone may open, sends facts to a language model, and writes comments and SARIF back. Some customers use it on public repositories.

Threat model the tool itself, not the infrastructure it reviews.

How would you threat model Wayne Citadel?

Cover these points. If you think the brief is wrong in part, say so and explain why.

Assets and trust boundaries
Attackers and entry points, including forked pull requests and malicious plan content
Prompt injection through resource names, tags and descriptions
Tokens and permissions: what the Action needs, and nothing more
Supply chain: our releases, dependencies and the model provider
Detection and response when something goes wrong
What you would test or fix in the first two weeks

0 words. Most good answers run 300 to 800.

Your answers are used only to review this application.

Tell us how you build.

Thank you.