In this presentation I present ways software engineers can incrementally secure the software development supply chain. Slides with speaker notes that include relevant URLs: https://docs.google.com/presentation/d/1atmuG420iuIKRh5LJX-N4SPTD8uuGbX5Htggxa8nMS8/edit?usp=sharing

1. 2017 CROWDSTRIKE, INC. ALL RIGHTS RESERVED.
make secure: Securing the
development supply chain
Wes Widner, Engineering Manager CrowdStrike

2. Setting the scene
“when I was looking at the nightly build releases, it looks likes
Libra was built on nightly builds of the Rust programming
language. It’s a little interesting because that's not how we usually
did releases in the DoD.”
Rep. Denver Riggleman (R.-VA) questioning David Marcus from
Facebook about the software dependencies in Libre

3. Developing a security mindset
▪ Developers often have incredible degree of access to critical
systems
▪ This naturally makes them targets
▪ This also makes them insider threats
▪ Appropriate paranoia, not unfathomable paranoia
▪ This means we need to scale our distress by the probability
and severity of the risk
▪ This helps us scope our efforts and make meaningful
progress in improving our security posture

5. “Having a well-done, nation-state-level
hardware implant surface would be like
witnessing a unicorn jumping over a
rainbow”

9. Owning the problem

10. Isn’t this AppSec’s job?
▪ A good organization will have a dedicated
application security team
▪ That doesn't absolve developers of being good
citizens instead of terrorists
▪ Castle security is dead, stop expecting someone
else to defend your fort
▪ Real layered security depends on every engineer
doing their part to secure their organization

11. McClure claims that first step in the Sony hack was a
targeted spear phishing attack that went after a
number of system administrators at Sony.

12. Control the battlefield

13. Choose your libraries wisely
▪ This involves asking several
questions:
▪ Is this library absolutely
necessary?
▪ Has another team already
chosen a similar library?
▪ How healthy is this library?
▪ Are you willing to care and
feed it?
▪ How could it break?
▪ What would it impact?
▪ How would I know?
▪ Proactively vendor everything
▪ Don’t automatically pull from
external sources

16. Choose your libraries carefully

19. Beware of entangling alliances

20. Keep your friends close
▪ 3rd party apps make our lives easier. We should recognize that ease comes
with a cost
▪ Each new integration comes with added systemic risk
▪ Be mindful of what you’re purchasing with that added risk
▪ Be proactive in securing these integrations

22. Everything you own has a
claim on you.
What you own requires care
and feeding. Otherwise, it
becomes a liability.

23. Set a good example

24. Be the change you wish to see
▪ As engineers, we can and should set the example for others to
follow
▪ Use password managers, secure enclaves, 2FA, etc.
▪ Don’t hardcode credentials into scripts and certainly don’t
check those into source control
▪ Embrace security controls, don’t fight them

25. Don’t take shortcuts!

26. Loose lips sink ships!

27. Use your influence wiseley
▪ We should use our influence over the systems we engineer to
make doing the right (eg secure) thing easy
▪ Be the one in the meeting who asks the hard questions about
security

28. Recognize the attack surface
▪ It’s broader than you think
▪ Don’t accept lame answers like “this will never be made
public”
▪ This has been the primary source of a number of high-
profile breaches
▪ This implicitly assumes a castle mindset
▪ Assume your environment is already breached and design
accordingly
▪ Don’t wait for an incident to come up with contingency plans

30. Be a security bar-raiser
▪ Stand up for ProdSec when they try to level up your security
posture
▪ Come up with fun ways to enable and encourage everyone to
be more secure
▪ Every little bit you do raises the cost to an attacker

32. Thanks for coming!
Contact me at:
▪ Twitter - @kai5263499
▪ Email - wes.widner@crowdstrike.com
PS We’re hiring engineers!
Talk to us at booth #50 in the hallway outside