Value Stream Mapping & Security in Software Development

The LEAN Enterprise management strategy puts value to the customer at the core. Once this is defined and established, it then suggests deploying business processes that will create this value, while optimizing the operation and minimizing idle time or any activity that does not contribute to that value.

The popular practice to do so is called value stream mapping (VSM). This practice details all activities taking place through customer delivery. In recent years, VSM – originally planned for manufacturing products –is also applied in application development, where all stages of the CI/CD pipeline are examined and calibrated against the VSM principles. Examples include matching pace of innovation to market requirements, tight and quick delivery between stages, and selecting the right personnel with the right skill set for each stage in application development.

However, as this practice was created for factories, it assumes easy identification of potential failure points. In modern application development and CI/CD pipelines, however, there are just too many moving parts to make good predictions or complete mapping. Not to mention the complex threat landscape which can cause disruptions, errors, and many iterations – everything but optimizing resources.

Simply put – security is not part of the deal. But it should be…so what do we do?

While there are various methods and metrics, all look at an application that supports the desired and agreed-upon business results. Therefore, the outcome should define the flow (per the LEAN doctrine).

Does your staff fully understand their role?

The first principle towards becoming most productive is when staff members understand their role, starting with the wanted business outcome and priorities. However, it is only to understand, not necessarily to implement.

[You may also like: Enhancing Application Security Processes]

We have discussed in the past how security posture weakens due to unclear boundaries of responsibilities between security staff and DevOps. Encourage information sharing between peers. A good step towards transparency and overcoming gaps in information can be a shared dashboard – unfortunately, there aren’t many tools today that provide it. Another solution is integrating DevSecOps engineers into the software development team. This may create some noise at first, but will help delivering secure applications to the customers – which is the ultimate goal.

Interoperability

Tight integration between activities will eliminate the dependency on tools and streamline production towards the goal. Looking forward into service-meshes, the degree of complexity will be higher due to the nature of distributed development where each team may be using different tools and practices. DevOps must find a way to integrate security tools well into the pipeline in a synergistic manner. Suggestion: look at the user : developer : security ratio and make sure it is in line with the value stream objectives.

Do you have the right architecture in place?

Working hard to put together a seamless, well-orchestrated and fully automated application infrastructure takes a lot of effort. The more elastic the infrastructure becomes, the harder it gets to calculate your constraints in advance. 

[You may also like: Application Security in the Microservices Era]

On one hand there’s better utilization of computing resources, but on the other it is harder to control the costs. How do you minimize risks? Were security considerations taken into account? Bad architecture leads to slowdowns, thus moving away from the desired value stream efficiency. It is double the trouble when vulnerabilities are being taken advantage of. Value Stream Mapping talks about removing inefficiencies. Is security vulnerability an inefficiency?

At this point in time, secure software is fundamental in value creation.

Suggestion: don’t release if security isn’t part of the process, or at least audited at a decent level. If you have to go back to do patches and fixes or add security layers on top at extra cost, that is very far from optimal resource utilization – certainly not LEAN. So don’t automate without speaking to the dev group. Developer objective vs. responsibility is currently in no man’s land.

At a certain point, you’ll have to justify decisions to peers, business owners or for compliance purposes. It may require raising your head above the water for a second to look far, but it will save headaches in the future.

Improvement

Another principle which may sound obvious is ongoing improvement. As far as application security goes, technology stands aside with continuous learning and feedback loops – during testing but also in production, thus making sure legitimate users are accessing our services and disruptions are eliminated. Improvement can also be an educational effort for developers, so they consider, for instance, access controls, tokens, keys or public cloud access credentials.

Quality also reduces risk because it raises the value delivered to the customer but requires the right metrics and analytics and this investment vs. premium are to be calculated. In software development though, delivering low quality product is painful and has extra costs and delays down the road. We suggest calculated quality with its associated costs (and sometimes risks) in every phase of the value stream.

Automation

Nearly all activities in the software supply chain are automated today…all except coding and security. Coding because there’s no replacement yet to the human brain, and security because it is perceived as conflicting with the agile objective. Some areas are easier to automate, are more intuitive – like testing. Scalable automation strategy covers a full diagnosis of UI, reliability, performance and complete unit testing – great success, right?

[You may also like: 4 Emerging Challenges in Securing Modern Applications]

However, if you are quick to put together a plan for the testing environment, you may find it harder to execute or to maintain. We suggest involving security experts in the discussion. There are tools today that allow scalable security as well, designed for modern dev ecosystems. Such tools go beyond code reviews and SAST/DAST to actual real time security – prevention rather than mere detection. Very important – don’t overlook the APIs. They are becoming a greater risk by the day.

To summarize…

Prospects see built-in security in your applications as value. Keep that in mind when designing the ecosystem and mapping all the different activities, responsibilities, and hand offs. Once you consider the costs of idle time, customization, bugs, fixing and patching, and then going back to fix security issues – the toll can be just too high. Identify problems at the earliest stage, long before deployment.

Today’s application development & production environments are so dynamic so there is no single truth, no single optimum, except secure your software supply chain.