Key Takeaways and Conclusions

I want to start by thanking you, the reader, and letting you know that I am deeply humbled and honored to be part of this community and to takethis journey with you. This may be the final chapter, but it's only another step in our trek together through a brave new world of democratized security.

Through the life of this book and my experiences in my career, I find myself always coming back to one common theme: reflection through introspection. Without introspection, we cannot truly delve into the depths of our abilities and create a better version of ourselves or what we control. At the heart of The Purple Book, we don't seek to give you a prescriptive compendium of frameworks and practices. Instead, we aim to provide a mixtape of perspectives and lessons learned.

Armed with this perspective, you can reflect and find your own way based on your and your organization's opportunities. Change is a deeply personal and often painful experience, but we cannot grow without that pain.

Without introspection, we cannot drive real change. It is easy to read the success or failure of others, cast our judgments, and beg, borrow, and steal the parts we find attractive to write our own narratives. It is exponentially more challenging to step back and say, "Wow, that must have been painful. What can I learn from that, and how do we move forward knowing this now?"

There is power in combining the right parts and parcels of concepts and experiences. Still, without a deep and introspective understanding of how change will impact our organizations and us, it is essentially lipstick on a pig, as they say. We must never forget for actual growth, there are no shortcuts. You must put in the work, and what works for one may not work for others. We must measure ourselves and our organizations against ourselves and our organizations, not against others.

The core of every goal is to become a better version of the current state. Yet this change cannot be achieved without a clear understanding of the current state.

Do not conflate growth with a competitive advantage. One is actual change, and the other is a byproduct of change. The goal is not to consistently be winning, but rather to always play the game and learn. True success is a complex tapestry of discovery, understanding, experimentation, luck, skill, and art. I solemnly wish that the insight imparted through our shared experiences in this book bolsters you on your journey to understand, contribute, and grow in the fast-paced, high-stakes, and dynamic security industry.

When I began my career long ago, I learned a valuable lesson: if you don't feel it, you won't change it. In that vein, here are a couple of stories that I hope will enlighten and inspire you to find your own path to the possible. It all begins with showing you why each of you is so vital to the process of democratizing security.

It’s easy to see the value of success when it’s laid out in front of you, but we often don’t have the opportunity to peek behind the curtain to see the monumental effort and absolute beauty of the stars aligning to create the success you see before you.

Answering The Question

For me, a defining moment was ignited by a simple question from a colleague. I was sitting at my desk, drawing on a massive dry erase board, identifying kaizen bursts on a value stream. I struggled with the feeling that something was still missing. We had come so far but still had so far to go. We had realigned to the Spotify model, we had established a transformation change agents initiative, and it was producing more value than I had anticipated.

Our team had founded a global architecture function, and it was maturing quickly. We were connecting deeper with development, customers, consumers, and the needs of our industry. Things felt right, but something was missing, and I couldn't put my finger on it. I went to a good friend, Rajan Gupta, to ask him how things were going in security. While we were having a conversation, I asked him where he thought security value existed that we still hadn't recognized or relentlessly pursued yet.

Little did I know the next question he would ask would change everything for me, reignite my love for security and set me on a journey toward new and   amazing aspirations.

"Sean, why is security built into every other engineering role but software engineering?"

Then he continued, "Think about architectural engineering: they build things stronger than necessary and have multiple fail-safes to ensure they know if there is a problem. Now think about electrical engineers: they leverage breakers to prevent overloads and turn off the power before changing an outlet, so there's no risk of electrocution. Now think about a civil engineer: they have safety built into the timings to ensure cars don't crash. Why doesn't software engineering have security built-in?" I responded, "That's an excellent question."

I'm not ashamed to admit I have spent countless sleepless nights agonizing over this question. I went to multiple conferences and events, asking this question over and over again, looking for perspective to enlighten me. I did research from the start of software development with Ada Lovelace to the current FAANG companies. In pursuit of this golden answer, I attended the RSA conference in 2021 to sit on a panel about the disruption mindset. After the discussion, I went out into the audience to meet and greet people who had questions. I came across someone I now consider a dear friend who was pivotal in answering the question that plagued my existence.

Little did I know that Nikhil Gupta would provide not only that elusive insight, but would also create a movement around solving it. Nikhil said,

"I have a dream to build a company that will bring a deeper and more meaningful way to bring security to software engineering."

I felt like I had been dreaming, and Nikhil had shaken me awake to discover a whole new world that had never existed. In pursuing that dream, he did indeed establish a successful company. A few months later, he reached out to me and asked another great question. How do we give back and create a community that will help practitioners democratize security so it's consumable by anyone?

At the time, there was so much noise around security with various vendors, products, webinars, and podcasts, and I honestly didn't know where to begin. So we did what many people do when they need to figure something out. We created a recurring meeting. As time progressed, were refined our ideas and brought other leaders into the room to gain more perspective. We outlined how we would do this, what we would do, and most importantly, why we wanted to do this.

Over the months, we met and discussed what was important, what was missing, how we could champion our vision in a meaningful and engaging way. Over time we developed a vision that reflected a past, present, and future that we could be proud of delivering, and that could stand the test of time.

“To build a purpose driven, trusted, and safe community that equips people with the expertise to embrace secure development practices, connect with other practitioners to solve the ever-evolving challenges, and ultimately democratize software security.”

This laid a foundation for building everything that The Purple Book represents. It became the blueprint for a community that had what a practitioner of any pedigree would need to learn, contribute, and grow in their own individual journeys to democratize software security. Shortly after, we began building the scaffolding for everything you see today and even some things we've yet to bear.

You may be asking yourself, "What answer to your question did you discover?" Well, my current understanding of "Why doesn't software engineering build security in?" is because of the pain produced due to connectivity. Turns out you have to feel the pain if you want to change it.

If an architectural engineer doesn't build in security, the occupants of the buildings will potentially be crushed in a collapse. If an electrical engineer doesn't turn off the breaker, he gets electrocuted. If a civil engineer doesn't time lights correctly, cars crash, and people are injured. In earlier days, the risk of pain was orders of magnitude smaller for closed systems but has grown substantially over time as we've become an interconnected world.

Anything from a medical device failure to an entire company security breach due to poor software security will result in pain. Pain comes in different forms, other than physical. Reputational damage, intellectual property compromise, data exposure, and personal losses such as identity theft or fraud are all pains we endure. What has happened to spur more extraordinary security practices when you think about your business? Who makes the changes, and when do those changes occur?

See the picture now? The proliferation of technology amplified by capability, needs, and growth for connectivity paints a vivid picture of how quickly we now can experience pain compared to the old world of closed systems. This underlines why software security is so critical. Change never occurs if leaders, developers, engineers, and operators don't feel the pain.

When we take a reflective approach and start asking the right questions, we have the opportunity to recognize pain before it becomes unmanageable. Over time this becomes an exercise in pain prediction. This process takes each and every person in an organization to be effective. Software security pains will always be there in some form, and it may feel like an overwhelming problem to solve. Only when we look inwards and start seeing things as exciting opportunities that could change the world do we begin to make incredible progress. This is why The Purple Book community exists.

Contributing To Our Future

If you want to see the big picture of what has been set in motion and what we hope to accomplish, I know of no better story than this one. It all started when Toyota once pondered, "What could we accomplish if we could find a way to eliminate waste and limit resources used in our organization? What would it mean to our people, our customers, our business?" They set out on their own journey with that single goal in mind. They discovered valuable lessons from William Edwards Deming[1] and Piggly Wiggly[2], to name a few, that would revolutionize manufacturing and create ripples of change far beyond their industry. Their lessons on introspection yielded value in the form of "The Toyota Way"[3] and "Toyota Production System"[4] and eventually what would forever cement them as a cornerstone to a concept called Lean. Their goal, however, was never to create a framework for the industry or the world to follow. And yet that is precisely what happened.

Toyota's experiences during this introspection period drove mainstay changes such as the continuous improvement and respect for people as pillars of their management approach. By going to the source of the facts and building consensus, they could achieve their goals at more incredible speed. This spawned new methods to achieve better security we still use today. Some of those notable contributions have been Deming's PDSA cycle (continuous improvement) framework[5], Sidney Dekker's concept of Safety Differently[6], and Frederic Laloux's advice process[7].

Toyota started with the simple question, "How could we be better?" The power of introspection drove revolutionary changes and iterations of some of today's most popular frameworks used in our own industry. It proves the most potent change doesn't come from replication but from introspection and the birth of new fit-for-purpose concepts. I can say with absolute certainty that they never imagined their reflection would have led to Lean when Toyota asked that simple question. That Lean would inspire Agile and that Agile would give way to DevOps, and that DevOps would signal change leading to DevSecOps.

Conclusion

It can feel overwhelming to try and make an impact. Know that it all starts with a simple question and ultimately grows through contributions to communities such as this one to mature it into its next phase of life. Through the action of every person who provided insight and learnings, DevSecOps is indeed possible today.

Bear in mind, the moral of this story, isn't that your organization should be more like Toyota or any other organization. Instead, each of us must seek out and discover our path. Your journey might be similar to another organization's journey, but it won't be identical. In all likelihood, it will be very different. Where you end up will depend on your needs and your situation.

In short, your process will be driven by your context and not by an arbitrary set of rules or concepts you find somewhere in a book or hear in a lecture. So as much as I'd love to say, "Hey, this book will tell you exactly what you need to know," that would be a highly inaccurate statement. We simply provide light to help you find your way forward and then apply the lessons you learn along that journey to achieve the state you desire. There's no such thing as a one-size-fits-all solution.

Our hearts are filled with hope not only for what you discover but the learnings you will share with others from your own unique experiences. Just the act of reading these words has been an investment in being part of history where your contributions will shape the future of our discipline, industry, and ultimately the world. Hopefully, The Purple Book will help you gain insight into valuable areas to start your explorations. We wish you good luck and good fortune!

Executive Perspective(s)