To shift left successfully, security must first focus on aligning the culture and building great development partners. It must also track useful metrics, document expectations clearly and ensure developers receive the necessary training to ease the transition.
This piece explains some common shift left best practices and offers tips for ensuring the move goes smoothly.
Shift Left for Security and Dev Teams
The term “shift left” became popular over the past few years, but it is not a new concept. The understanding that it is cheaper to fix problems the earlier you are in a process has been around for decades within the application development arena. This
more recent push centers around giving developers the tools to quickly identify security issues and correct their code early in the development process.
When security initiatives are pushed onto other teams within the organization, those teams often perceive it as slowing them down. To be successful, then, security must gain partners and have a consistent message that centers on helping those partners
do their job. Take, for example, the perception of security being a roadblock for features. Instead of arguing it is a necessary roadblock, we recommend turning the conversation to:
- Reducing defects within the codebase that later could impact performance
- Improving user experience
- Speeding up deployments through automation
- Fostering proper stewardship of data
Be sure to communicate the fact that security will work with them to procure and recommend tooling that helps developers write better code, faster and easier, while still meeting company expectations and objectives.
Security cannot sustain positive change by issuing demands and heavy-handed requirements. Developers must understand they are getting value from the changes proposed, or they will simply avoid doing anything you lay out. To shift left successfully, you
must convince partners and get them on board to integrate additional checks into the process.
Shift Left Tips
Enlist a Security Champion
One option to help with your message is to develop an ambassador or champion program for secure development practices. This entails finding developers within the various teams who have a passion for secure coding practices and who will echo the importance
of it through the software development lifecycle (SDLC). This can be done by asking for volunteers or offering application hacking workshops and looking for interested individuals.
We suggest incorporating these developers into the security design and decision process to establish a good-faith relationship. Having them involved in the input phase fosters trust and enables them to provide candid feedback on what can work within the
organization and what to avoid when implementing. These partners can also help when a decision about tooling or process is made and must be integrated into the SDLC.
Focus on Real-World Issues
Sometimes developers don’t understand why certain tools or processes are needed at all. If that is the case, show them the state of application security via internal assessments, third-party assessments or via a bug bounty program on the application.
Detailing the existing security defects provides a realistic picture of the issues and the need to address them.
Set Clear Expectations
Setting expectations for your developers is critically important. Documentation is one of the most valuable things you can do here, although it can also be the most time-consuming.
Your goal should be to give clear direction on what you expect developers to incorporate into their designs and codebase. Use clear, concise requirements that are easy to understand and apply to development work. This should also be integrated into a
knowledgebase tool, such as an internal wiki.
Consider incorporating typical coding samples that show how to securely configure common tasks, such as:
- Handling authentication
- Dealing with user input
- Querying a data store
- Managing secrets
- Handling output sanitization
Put Metrics in Place from the Start
Telling a story of success requires showing where you came from in the form of metrics. Consider tracking metrics like:
- Time to deployment
- Security defects fixed per accepted severity timeframes
- Percentage repository adherence to expectations/controls
- Time to open/close security defects
- Median/average security defect lifetime
By incorporating metrics early, you can send a message to management that either the security investments made are working or that adjustments are still needed to realize the actual value.
Once you have an agreed-on list of meaningful metrics, be sure to share them with all interested parties, including management, development teams, business unit leaders and security staff. This both lets people know how they are being measured and fosters
full transparency.
Automated Tooling
One primary way developers and security professionals integrate security checks is through automated tooling that helps ensure code conforms to security expectations. These include:
- IDE integrations. In addition to providing developers with standard sample templates of secure coding practices, you can also incorporate inline suggestions on coding best practices, including security issues. Check what integrated developer environments
(IDEs) your developers use (e.g., Visual Studio) and look to see if they have security integrations. Certain programming languages also have marketplace tools that show security corrections during development.
- Linters. These programs help identify security problems early in the development process, such as coding-style errors, programming mistakes, exposed secrets within repositories and other common security issues. Linters should be used at various stages
within the code pipeline to ensure issues do not proceed when committing code. Most programming languages have several open source options, and commercial linters are available as well. Additionally, developers should use them to validate their code
to avoid pipeline failures.
- Security scanners. Much like linters, deployment pipelines should generally be integrated with static and dynamic application security testing (SAST and DAST) tools:
- SAST tooling should be incorporated early in the commit process because security issues should be returned to the developer if valid. You eventually want to integrate this into the pipeline as a check, so you can fail the build if there are problems.
However, newly integrated tools often come with a multitude of issues, including false positives. Security and development teams must work through customizing the rules to ensure this is not overly burdensome out of the gate.
- DAST tooling is typically integrated into the process when the code is deployed to an active environment, like a staging environment. This allows for the testing of some business logic and access controls that cannot be tested by a static analyzer. If
there are credentials within the application, the DAST should be given roles to ensure permissions are sufficient and tested across the application's functionality across the entire programming landscape.
Both SAST and DAST should be accessible to developers so they can launch testing on a shared codebase. This may be more complex, given the distributed nature of the application and using a DAST tool. However, there are ways to deploy an environment for
testing, given specific cloud deployments. Options may include setting up a dedicated staging environment or allowing developers to spin up full environments.
Training for Developers
Once you decide on the tooling and process adjustments, developers must be trained to understand and use these tools, particularly if they impact deployments. Ensure developers understand the reasons to use these tools and how to integrate them into their
development process effectively. You should also ensure these processes are well-documented within the maintained knowledgebase.
Shift Left Roadmap Advice
Taking on a shift left roadmap requires a strong partnership between security and development. To ensure success:
- Approach the initiative with a helping hand. You will gain developer trust and the program will be more sustainable.
- Track your progress. Metrics help demonstrate that what you are doing works to reduce security defects. Be sure to start tracking key metrics immediately to show early wins.
- Align and integrate security tooling to your specific environment. Ensure anything you use is well-suited to support every facet of your deployments.
- Set clear expectations. Ensure developers understand what is expected of them. Develop great documentation and sample code, and be sure developers are trained to use the tools properly.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.