I’m at the OWASP AppSec Cali event, and while there’ll be video, I’m taking notes:
Context for the talk
- What fails during the development process? Incomplete requirements, non-secure design, lack of security mindset, leaky development
- These failures are threats which can be mitigated. (eg, compliance and risk requirements address incomplete requirements)
- We keep failing in the same way. How often are developers required to pass a security interview to get a job?
- Story of Alice the manager, and Bob the developer who learns about a SQL injection in their legacy code. Bob is overwhelmed by security requirements.
- “The problem with programmers is that you can never tell what a programmer is going until it is too late.” — Seymour Cray
- Security team objective: be informed about product flow; help developers not write and not deploy security issues; stop being a bottleneck; so focus secure development on the developer, not the security expert.
Notable Security Events
- How to integrate security expertise into development in a more fluid way. Does this tie to “the spec”?
- Developers don’t know that their changes are security relevant
- Funny example of a training quiz that doesn’t have a learning goal
- Noel Burch’s hierarchy of competence. From unconscious incompetence through unconscious competence.
- Learning: step-by-step, instructions, theory; training: repetition, muscle memory; applying: real life doing.
- Tie domains to notable events, use checklists for those notable events.
- Specifically formed “if you did X, do Y.” Each “Y” must be in the language of the developer, concise, testable, and supported by training.
- Ran an experiment, got solid feedback.
- Short training gets used more.
- Crisply defined responsibilities by role.