With our Neuvik Editorial Insights series, we highlight the expertise of our team and showcase their individual thoughts on the cybersecurity industry today.

Introduction

Product security is hard to tackle, especially for established organizations that are just starting to integrate security elements into their existing development practices, otherwise known as “secure by design” or “security as code.” Introducing these elements into a developer’s already hectic daily activities can risk the developer viewing security as an adversary rather than an ally.

For that reason, security should be a first principle, not an externality to development practices. By shifting the mindset to include security in the beginning of development, developers’ day-to-day can stop being interrupted by security additions after the final product is “completed”; thus, security can be a part of products themselves, rather than “bolted-on” as appliances and incomplete solutions.

Adding security while development is in-process is traditionally referred to as “pushing left”, but I propose we view it instead as “pulling from the right.”

How is security traditionally introduced? By “Pushing Left,” of course.

“Pushing left” results in the discovery of potential vulnerabilities occurring earlier in the product development lifecycle, allowing for removal or mitigation of issues. This short-circuits the need to re-perform units of work, which is fundamental to the concept of modern application security.

However, no one wants to feel “pushed.”

While software development is a giant machine that takes in requirements and churns out executables, it is made up of people like any process-driven system. Trying to tackle any problem of scope without paying mind to the people involved endangers the security process from the start. So that’s the first step in introducing security in development: recognize that you’re dealing with people who understand the responsibilities and goals within their work. Development teams are made up of people who have internal and external requirements, mitigating factors, and likes and dislikes. Bringing this people-centric step into the process first helps ensure the people doing the work understand the goal before they get started.

While software development is a giant machine that takes in requirements and churns out executables, it is made up of people like any process-driven system.

Ultimately, any change in duty or process is best served when preceded by attempts to shift the overall culture — both of the organization as a whole — and of the development teams within. Assigning new duties to developers without an understanding of the underlying “why” does not set up the process for successful security implementation. For example, a change in responsibility and scope for someone that comes in day-in and day-out to perform their job should never feel sudden, but instead, carefully considered.

Instead of viewing the introduction of security (whether called “DevSecOps,” “secure by design,” “security as code,” or tomorrow’s nom de jour) as a “push” operation — where elements external to the development process are pushed into it — we as leaders need to remap our thinking and consider “pulling from the right”.

Building a Culture of “Pulling from the Right”

So, how do we start creating a culture of security? How do we show the value of these new tasks in a way that will encourage their adoption by developers?

Foundationally, as security experts, we can start by meeting developers where they are. Remember that DevSecOps et al is just as much about bringing a development mindset into security as it is about bringing a security mindset into development.

One way to start is with something familiar — the development lifecycle as it exists in your organization — and show what changes can be made, why they should be made, and the practical impact on the development cycle as a whole. Demonstrate the impact of security mechanisms on the end user, on the systems running the code, and on the code and data itself. Illustrate where work upfront will save effort in the long run.

By sharing an understanding of the goals of security, and the already existing costs, the value of shifting those costs starts to become apparent on its own.

Focus on the “what” and “why” first. The “how” may change over time, even during the initial rollout or adoption, but the underlying reasoning, the first principles behind the change, will remain.

Gaining a shared understanding of the underlying reasoning behind security may also mean that the rollout of individual processes may have to be multi-phase. That is, it may be necessary to begin with a manual, hands-on, phase first — to illustrate the issue and its solutions in a readily absorbed way — before shifting to or augmenting with automated processes and tools.

And, crucially, do this before and during the process of introducing new mechanisms and practices. Once everyone is on the same team and the same page, nothing is going to be “pushed” anywhere — the team works together to pull, absorb, and integrate elements into all aspects of the process. This is the culture we need for long-term change.

Once everyone is on the same team and the same page, nothing is going to be “pushed” anywhere — you’re going to work together to pull, absorb, and integrate elements into all aspects of the process.

Let’s talk

Culture change works best with strong knowledge sharing and strong foundational knowledge. We can help with both through training and through a holistic enterprise-wide approach to threat and risk.