A Nordholm Systems engineer proposes dropping fuzz testing from the verification checklist, pointing out it’s used far less than almost anything else the team does. Before agreeing, the security lead checks how engineers rate fuzz testing’s impact when they do use it — and finds it rated meaningfully more impactful than dynamic analysis, a much more similar-sounding activity that also sees low use. What best explains fuzz testing’s rare use despite its comparatively strong impact rating?

Nordholm Systems’ security lead pulls together data across the company’s dozen agile teams and finds a pattern that puzzles her: activities the teams use most often are, on average, rated by the very engineers using them as only moderately impactful on security — while some activities used far less often are rated as highly impactful. A colleague asks what would cause usage rates and perceived impact to diverge like that. What best explains the divergence?

At Nordholm Systems, a team lead proposes moving the project’s threat-modeling and secure-design work from its current spot — right before release — to the very start of each feature’s development, even though it means more up-front discussion time. A skeptical colleague argues this is just extra process for no real benefit. True or False: moving this work earlier in the cycle is likely to make it more effective, not less.

Trellis Health’s Scrum team has finished implementing a patient-scheduling story. The developer marks it “done” because the feature works exactly as the acceptance criteria describe. A security reviewer flags it anyway: the story’s Definition of Done never mentioned encryption, session timeout, or audit logging, so none of that was checked. Whose omission is actually responsible for this gap?

Nordholm Systems’ verification-phase practices span a wide range: automated testing tools, manual code reviews, dedicated security test cases, penetration testing, and more. When the security lead asks which single practice her engineers both use the most and rate as most impactful for security, one activity stands out clearly above the rest. Which one, and why does that pairing matter?

Nordholm Systems’ security lead ranks the company’s design-phase security activities by how often teams actually do them. Application security configuration comes out on top for sheer frequency of use — yet when the same engineers rate how much it helps security, it scores among the lowest of any design-phase activity. Meanwhile design requirements and abuse-or-misuse cases are both used often *and* rated as genuinely high-impact. Which of the following statements holds up against that pattern? (Select all that apply.)

At Nordholm Systems’ next retrospective, the team compares its implementation-phase practices: coding standards are followed almost universally and engineers consistently rate them as one of the most valuable security practices they use, while more specialized security tooling sees much lower adoption. A new hire asks why something as basic as a coding standard would rate above dedicated security tools. What’s the likely explanation?

At Nordholm Systems, architecture and application-development guidelines are one of the requirements-phase documents nearly every team consults, yet when engineers are surveyed internally on how much those guidelines actually contribute to security, the ratings come back surprisingly low. A junior architect assumes this must mean the guidelines are outdated. What’s a more likely explanation?

After a sprint, Trellis Health’s scheduling feature passes every acceptance test the product owner wrote: patients can search for a slot, book it, and receive a confirmation, exactly as the user stories describe. The team demos it and calls it secure, since “all the tests are green.” What’s the flaw in that conclusion?

During a pre-launch security review of Northfield Retail’s checkout platform, the audit team finds a customer-profile page that renders a shopper’s saved display name straight into the HTML. A developer on the call argues it needs no special handling because the value came from Northfield’s own database and is therefore trusted — until the auditor points out that a display name saved months earlier is already firing a stored XSS payload in every visitor’s browser. What principle should have been applied?