Security Engineer, Amazon

• Experience applying threat modeling or other risk identification techniques or equivalent
• Perform offensive testing of web applications and services, and source code review, to identify non-trivial issues
• Script your way out of problems and deploy code in an enterprise environment
• Experience with AWS technologies and services (e.g. S3, Lambda, EC2, KMS, IAM)
• Be data-driven and support your conclusions with evidence
• A Bachelor's degree in Computer Science, Cybersecurity, or a related field, or equivalent professional experience
• Experience in professional penetration testing, source code auditing, bug hunting, or CTF experience
• Demonstrable depth in at least two complex security domains such as identity and access management (IAM), web application and API security, networking, or workload and tenant isolation
• Experience finding security issues in multiple languages, including one or more of Java, Python, JavaScript, Rust, Ruby and C
• Experience in code development using Python or an equivalent language, including boto3

Desirable

• We are looking for a Security Engineer to join Continuous Security Testing (CST), the AWS team that thinks like an adversary against systems running in production. You will follow real-world signals to where testing matters most, work out what an adversary could do, and leave behind detections and tools that keep watch long after you've moved on
• Amazon Web Services (AWS) is the leading cloud provider. Businesses of every size, from start-ups to large enterprises, run their most sensitive workloads on it. As AWS grows, the surface we need to test grows faster than any team could keep up with by effort alone. CST meets that by pairing deep human expertise with signal-driven, AI assisted testing, so coverage grows with AWS rather than falling behind it
• We work from real world signals, such as threat intelligence and automated scanner output, to decide where testing will matter most. We steer AWS's most advanced AI tooling to hold the bar, then apply human judgement to raise it: imagining how an adversary might combine behaviours nobody thought to put together, adding the business and service context a model lacks, and designing the abuse cases that still need a person
• This is creative work. The most valuable things we find are the ones nobody knew existed: new techniques, novel attack paths and ideas that no checklist or scanner would ever suggest. We want engineers who love asking "what if?" and following the answer wherever it goes
• You will decide where to look, as well as test what you're given. You must produce results in ambiguity, follow a signal wherever it leads, and drive resolution with teams outside your own when a fix isn't simple
• You will deliver independently, ask for guidance when a problem moves into unfamiliar territory, and say clearly when a line of investigation should stop
• Turn real world signals, threat intelligence, scanner output and past findings into testable hypotheses about how an adversary might think about systems in production
• Test live AWS services and internal systems, combining penetration testing with AI-augmented source code review, and direct the tooling at trust boundaries and attack paths it would not reach on its own
• Bring creativity to every investigation: invent new techniques and research areas nobody has explored yet
• Investigate whether something novel you've uncovered could apply across other systems, then prove or rule out impact end to end with safe, reproducible proof-of-concept work
• Trace attack paths across chained components to show compound risk that stays invisible when each component is tested alone
• Take each finding to a resolution: work with service teams, SecOps and AppSec on the fix, validate it, and check the fix can't be bypassed
• Turn what you find into lasting defences, such as detections that run across the fleet, security canaries, fuzzers and documented methods, and track whether other teams adopt them
• Build and tune the harnesses that steer the team's AI testing tools, measuring where they miss attack patterns or produce false positives
• Test agentic AI systems as an adversary would, including tool use, memory, agent-to-agent communication and orchestration
• Write clear results that record what you tested, why, what you found or ruled out, and the risk that remains
• Peer review other engineers' scopes and findings, and mentor engineers and apprentices on the team
• Your morning might start with a cluster of real world signals that hint at something nobody has looked at yet. You form a hypothesis: if one system could be built this way, could others? You point the team's AI tooling at the source code to find candidates, then test the most promising ones by hand
• By the afternoon you've tested your hypothesis on one system and know exactly what an adversary could or couldn't reach. Now the question is scale. You write a query to see whether it could apply more widely, prove or rule out the worst cases safely, and agree priorities with SecOps and the service teams that own them
• Over the following weeks you stay with it. You review the proposed fix and check it can't be bypassed. You work with a detection team to turn your test into a check that runs across the fleet without you, so what you discovered keeps protecting AWS wherever it might appear
• In between, you review a peer's scope before their testing starts, help an apprentice through their first proof of concept, and share what you learned with the team so others can build on your idea