Actions to Introduce Application Security in DevSecOps
Developers are busy and introducing new tools or new processes is often met with resistance, and rightfully so. This is compounded when developers don’t understand the value of these changes in workflow. It’s easy to think “I’ve got enough to do already, is this tool just creating more work?”
The solution to this is twofold: The value and usefulness of any changes in the developer workflow needs to be well communicated. Without buy in at all levels of the development team, adopting new tools and processes often fail. Secondly, developers need to understand how to use the tools and make use of the results. If the perception (and practice) is that the tool just causes confusion and extra work.
1. Get Everyone on Board?
Communicating the value of a new tool or process to the entire development team is essential for buy-in. Obviously, there will be resistance and skepticism, but the key is to communicate the end value of the change.
The value proposition for SAST is strong and varied but it can be boiled down to one key activity: remove bugs and security vulnerabilities before they make it into the product. Keeping these bugs out of your finished product is worth a lot of money, time, and reputation. Unless the team sees the value in this pursuit, adopting SAST is more difficult.
The first step to prevent overwhelming the development team is the broad acceptance that the end justifies the means. The desire to improve the quality and security of the software is needed to overcome barriers to adoption.
2. Manage Demands & Don’t Get Overwhelmed
There are some early steps that to take to prevent SAST tools from overwhelming the development team. First and foremost is setting an achievable goal as the starting point.
Determine the end goal: Without a clear goal it’s difficult to measure success against. Is the goal to increase security? Reduce the number of defects in delivered products? Achieve compliance with a coding standard? It’s critical to set goals as this drives the way SAST tools are to be used within the development process. Just like a personal goal, it should be achievable in a reasonable time frame. Focusing on a key criterion also gets the most value out of tool adoption.
3. Start Small, Go Big Later
The first instinct when adopting SAST tools is to try running them on everything – integrate the tool into the full build and analyze all the code with the tool’s default settings. This approach naturally produces a lot of warnings. The reaction to this is either “we have a lot of problems to solve” or, the more likely, “This is all a bunch of uninteresting noise.”
This is exactly what we try to avoid with new SAST tool integrations. However, it’s a natural tendency to “test out” tools in this manner. Luckily, you can still work with this initial full build analysis since it creates a baseline to work from.
“Avoid running SAST on everything at the start.”
Configure the tool: SAST tools have configuration options that enable/disable warnings or even whole classes of warnings. It’s important to configure the tool to match the desired goal. The early instinct is to enable everything, however, starting with small subset is best. If security is the focus, enable the highest priority security warning classes only.
Establish a baseline report: The initial report is an important starting point for adopting SAST. The key thing here is to not be intimidated by the number of warnings. There are strategies to deal with this over time and not all warnings are of equal severity. Tools such as GrammaTech CodeSonar provide a useful score with each warning.
Stop the bleeding: To start improving the quality of a project, it’s important to make sure that no new defects are being added as code is changed or new code is added. This is done by creating a comparison between the latest report and the baseline report to look for new warnings that were introduced due to new code, or changes to old code. The priority should be on fixing any new defects introduced during each iteration.
4. Pick Your Battles
The instinct, especially for management, is to fix all the warnings that SAST tools report. This is justified in certain types of applications but, in most cases, it’s better to prioritize and fix what is reasonable in the current iteration or sprint.
Use the information the tools provide: An often-overlooked aspect of SAST tools is their data management capabilities. There are several ways to help developers focus on the most important warnings. Warnings need to be classified by severity and in the case of CodeSonar are given a score which combines both severity and likeliness of warning be a real defect, a “true positive”. Prioritize the highest scoring warnings first.
Tackle the backlog over time: SAST tool reports don’t add to existing technical debt (despite the perception) but rather shine a light on what’s there already. Using the filtering and searching tools built into advanced tools such as CodeSonar helps prioritize the warnings for remediation. Concentrate on the important defects to get the most ROI from static analysis.
5. Integrate into Your Workflow
SAST tools integrate in two main points in the development toolchain – the developer desktop and the application build system.
SAST at the Developer desktop: The developer IDE is where warnings related to their current work are organized. In most cases warnings are presented in the same manner as compiler and build errors. Information is provided directly in the IDE to help fix the problem then and there.
Integrate into CI/CD pipelines: Integrate your SAST tool with one of the popular orchestration tools such as GitHub, GitLab or Jenkins. For example, plug ins are available from GrammaTech that integrate CodeSonar analysis into GitHub and Gitlab with various triggers such as merge or pull requests or for scheduled builds.
To smoothen the integration of SAST into the workflow, it’s important to remember the recommendation to “start small, go big later.”
Roll out to developers in stages: At first, it makes sense to get developers to tackle new, high severity warnings. As comfort with the tool improves, the backlog of security warnings can be introduced. It’s important to avoid the desire to tackle more warnings that developers can manage.
Automate merge requests: Add SAST analysis with every request. In this way, security analysis is done in real time helping to prevent or detect vulnerabilities before they make it into product.
Summary
Get buy in. Set a goal. Start small, go big later. Pick your battles. Integrate into your workflow.
The best way to stop overwhelming software development teams with SAST tools is a commitment to the value of the tools in the first place and communicating this value. Tools such as CodeSonar already have the technical capabilities to ease adoption, using these capabilities is key to success. Setting an achievable goal then starting small means concentrating on the highest priority warnings (and warning types) first then maturing your tool usage over time.
Success also means integration of SAST into the CI/CD pipeline and developer workflows. Tools such as CodeSonar provided integrations into all the popular build, issue tracking and source control products. In addition, integration at the developer desktop catches those high priority security issues before they even enter the product.
