Process

Author’s Note: A strong and successful software security posture requires several discrete elements coming together in a harmonious and consistent manner. One such element is Process. Organizational needs are diverse and customized based on different factors such as industry, size and maturity of the business, and risk appetite. Process in its basic form is a series of activities performed in a set order to achieve a predetermined outcome.

Processes can be strong enablers. Yet it is important to be mindful of the business state while attempting to implement any processes within the software security framework. A carefully formulated framework to implement key processes is therefore essential to the ultimate success of the security posture of any organization.

As we look at different situations, remember there is no one-size-fits-all approach to process implementation. Each industry and organization situation ultimately dictates the value that process implementation brings to the table.
‍‍

Finding the Balance

Process means different things to different people. It’s highly subjective and context-dependent. It varies by organization, by department, by function and by level. No two entities describe it exactly the same way. That said, processes are essential to the operations of all companies, from small family businesses to global corporations. The hard part is finding the right balance. Too much process can limit creativity and innovation; too little process can lead to anarchy and chaos.  

At its very core, process is a group of activities which are predictable, can be condensed into a framework, followed across multiple use cases and measured consistently. Anything and everything we do in the security space follows some kind of process. In security, we can’t afford to just “wing it.” We need frameworks, structures, guardrails, and checklists.

There is a misguided assumption, however, that processes need to be formal, inflexible, rigid and documented meticulously. Those absolute qualities aren’t necessary. In fact, they can become impediments to success. It’s fair to say that most of us intuitively understand the value of process. Even in Agile and fast-moving shift-left industries, process has become the norm; Agile itself is a process for managing software development lifecycle. That’s especially true in the areas of cybersecurity and application security. When we think through our objectives and formulate our action steps, we are following a process.

Larger organizations tend to have a core of formal processes. Smaller and leaner firms, and start-up organizations, tend to function on an ad hoc basis, relying less on institutional knowledge and more on instinct. In small-scale entities, individuals determine which processes to use and which to skip, based on the immediate needs of the moment. In a small company or startup, the prime objective is finding processes that will lead to successful outcomes.
‍

Aligning and Integrating Processes

For decades, Waterfall methodology was the standard process for developing software. Agile dates back to 2000, and has grown dramatically in popularity for a variety of good reasons. It’s safe to say that Agile has become the process of choice in the software development lifecycle (SDLC). In particular, Agile has become the standard methodology for general cybersecurity and application security. Ideally, DevSecOps will also become an integral part of the SDLC. Let’s put it bluntly: If we’re serious about building security into software, DevSecOps must become part of the standard software development process. It cannot be an afterthought or add-on. Building secure software requires thinking about security controls in every phase of the design process.

By adding software security components to the SDLC, DevSecOps enables the larger processes of digital transformation, and plays a critical role in the continuing evolution of computer science. DevSecOps makes perfect sense in Agile development scenarios, in which processes are broken down into small, manageable chunks that can be improved relatively easily over successive iterations.
‍

Pushback From Developers

For many organizations, shifting from Waterfall to Agile is not an easy or natural transition. Adding DevSecOps to the mix can make things even more difficult. Developers are likely to push back, asking why they should be required to add extra steps to their process, especially when such steps may delay the release of a software product.

As an executive, it’s your job to find a sensible balance between meeting production deadlines and integrating DevSecOps processes into the SDLC. Moreover, you must make the case to your developers. The last thing you want is for the development process to stop midstream.

In the real world, you cannot simply ask developers to stop what they’re doing until you catch up with them. That would be a recipe for failure. Instead, you need to make sure that the addition of security controls becomes a seamless and largely automated process. You don’t want the developers to feel as though you’re asking them to do more work – that’s why you automate the process of adding security as much as you possibly can.

Developers face a host of challenges; understanding their pain points will enable you to form trusting relationships and effective partnerships that result in better outcomes for the organization. These partnerships will prove essential over time, and in fact, they can become a competitive advantage.  

So, who is responsible for creating and nurturing these kinds of valuable partnerships that will ensure the inclusion of security features into all software releases?

From my perspective, the responsibility extends from the engineering leaders all the way down to the individual developers. But the responsibility to evangelize and to explain the value of these partnerships sits with the security leadership. As security leaders, we must take ownership. We must drive the empowerment and the collaboration, and we must act as credible role models. Merely telling people what to do will not solve the problem. We need to show them how adding security into their products will create tangible value.
‍

Shifting the Mindset

 At the heart of our challenge is this question: How do we make sure that developers are mindful of security without interrupting their workflow? Achieving this mindfulness requires both a shift in process and a shift in mindset. In this situation, the process underpins and supports the new mindset. Together, they enable execution.  

Additionally, a certain degree of practical experience is necessary to achieve the shift in mindset, because you will need to understand the stages of the SDLC to know when and where to insert the security components. This is where experience matters. You have to understand the software development process at a fairly granular level of detail if you want to succeed as a security leader.

An overarching problem, relates to the size of the organization.  In large and mature organizations, inertia and entrenchment will be the major obstacles to success. On the other hand, larger organizations usually have the resources necessary for driving change and making sure that new processes are adopted.

In small organizations and startups, there may be less inertia and resistance to change, but the lack of process and structure can impede the adoption of newer methodologies, especially if it seems as though the newer techniques will slow the pace of development.

In either case, however, it’s imperative for the security leader to understand how developers work and think. For example, it’s not unusual for developers to build their libraries from open source code. From the developer’s point of view, this makes sense. But from the security leader’s perspective, using code from potentially insecure sources is flirting with unnecessary risk.

A better strategy would be for the organization to set up an internal repository of secure code and then to encourage the developers to point their tools at the internal repository, instead of pointing them at external sources that may have security issues. If you don’t have the resources to set up an internal repository, there are vendors who will provide scanned code libraries. That’s another option for dealing with the problem.
‍

Do Not Interrupt the Workflow

Whether you set up an internal repository or pay vendors to provide secure code libraries, you wouldn’t be requiring the developers to change their process or alter their workflow – you would just be requiring them to point their tools at an alternative source. From a security perspective, you are accomplishing an important goal without interrupting workflow or sacrificing productivity.

Let’s remain on the topic of code libraries, which are essential to the software development process. The code libraries used by your organization’s developers should reflect the needs and characteristics of your organization. And they must contain secure code, which means you have to provide alternative sources of code that are safe and secure. That’s a key takeaway for security leaders.

Because you simply don’t have the bandwidth or the budget to check every library. That said, not every code library is created equal. Some will be more critical than others, and those critical libraries deserve the most scrutiny. Assessing and addressing the vulnerabilities of your code libraries will probably follow the same basic pattern (i.e., critical, high, medium, low, incidental) that you would use to assess and address potential vulnerabilities in other systems or data bases.
‍

How Much is Too Much?

Some people ask me if there’s a way for determining how much open source code should be used in software development projects. Frankly, I think that’s the wrong question. A better question is, “How do we determine if the code we’re using is safe and secure?”

The answer to that question will be different for every organization. In other words, there is no right answer or simple rule of thumb. A lot of it will depend on your ability to understand your organization’s software development processes and structure solutions that work for your organization. As mentioned earlier, the more you know about your process, the better you’ll know how to address potential problems in the SDLC. Trying to set arbitrary rules or set goals based on external expectations is rarely a good idea.
‍

Code Scanning

Code scanning is another area in which shifting the mindset of developers will likely produce better outcomes than taking Draconian measures after the product is largely finished.

There are different types of tests that can and should be performed at various stages of the development process. If you’re following an Agile process, you’re going through sprints or iterations. Testing will provide developers with important feedback, and enable them to fix problems on the fly, rather than waiting until the end of the process. It also enables you to insert security controls while the product is in development, instead of bolting them on later and hoping for the best.

Again, you need to be familiar with the different stages of the development process, because testing will differ according to which stage you’re in. What you test and how you test will depend on the stage.

Also, make sure that you automate as much of the testing as possible. Remember, the goal here is seamless testing with minimal disruption to workflow. Basically, you want testing to become invisible and automatic, like breathing. That’s the analogy I like to use. Testing is absolutely vital, whether we’re aware of it or not. And I’ll extend the analogy to cover all of the processes around application security. Like breathing, security is essential for our survival, even when we’re not thinking about it consciously.