As software organizations try to bring security earlier in the development processes, what can or should regular software or operations engineers know about security? Taking as given that we want them to build secure systems, that demands a shared understanding of the security issues that might come up, and agreement on what that body of knowledge might entail. Without this knowledge, they'll keep building insecure systems. With them, we can have fewer recurring problems that are trivially attackable. Training everyone at a firm is expensive. Even if the training content is free, people's time is not. If you have 1,000 people, one hour per person is half a person year (before any overhead). So there is enormous pressure to keep it quick, ensure it meets compliance standards like PCI, and … the actual knowledge we should be conveying is almost an afterthought. We need to design knowledge scaffolding and tiered approaches to learning, and this talk offers a structure and tools to get there. We don't need every developer to be a fully trained Jedi, and we don't have time to train everyone to that level or even as much as we train security champs. So what could we ask everyone to know, and how do we determine what meets that bar?