The world of software development is relying more on real-time data every day, creating new opportunities for bad actors to infiltrate a network. The growth of online data is providing up-to-date intelligence and operational awareness, but also highlights the need for improved AppSec awareness across the United States.
It’s often a challenge to ensure software developers are focusing on security in addition to their already long list of daily responsibilities. Despite improvements in tools, such as Software Bill of Materials (SBOM) and Software Composition Analysis (SCA) technology, to analyze software environments, security teams will continue to depend on others to implement and deploy security updates and policy changes.
Expecting software engineers to be fully educated in security best practices, and motivated to prevent security issues in their daily work, is a lofty goal. As a software engineer for more than a decade before joining the security industry, I pledged to help build this next stage in our software engineering evolution. I know we can get there, but first, we as security professionals need to provide more clarity to our engineering partners.
As publisher Karen Austin put it in the last issue, we can’t let ourselves get distracted by “The Current Thing,” to the detriment of real, ongoing and critical issues. Some of these critical issues are awareness of where data is stored, knowing which data is most valuable to protect, and building the habits to protect the data.
The issue is that engineering teams are already extremely busy with developing new business features, doing code reviews, building unit tests, fixing production issues, and many other things including longer-term work of architecture design, fixing technical debt, plus keeping up with the latest trends in development practices. If security teams expect developers to excitedly jump on board to tackle another list of security to-do items, they’re not paying enough attention. To effectively encourage change in habits, security teams need to make it as easy as possible for engineering teams to consume and address security concerns.
This means providing clarity about which security vulnerabilities exist, which systems need to be prioritized if there is a breach, and the time expectations for remediation so developers can fit security changes into their regular agile development cycles. So how do we do this?
The Single List of Security Findings
The traditional method of blindly throwing security findings “over the wall” at engineering teams is inefficient and causes a whole manner of confusion, especially if you have multiple security teams sending vulnerability reports from different tools. In addition, asking developers to look at dashboards of all security issues across an organization to find the ones pertinent to them is not the best use of their time, and will simply be ignored compared to their other priorities.
You need to make it easy for developers to know what to work on, when the work needs to be done, and how to incorporate the tasks in the organization’s normal software development process. Step into their shoes, put on your empathy hat, and meet the software team where they are, instead of requiring them to come to you. This level of accommodation is something we emphasize at Fivetran to maximize the efficiency of our engineers.
To accomplish this, create a curated list of security findings for each team, ranked in priority order based on calculated severity and additional relevant attributes, including the source of the vulnerabilities which can help determine the relative validity of the finding – Dynamic Application Security Testing (DAST) findings tend to be more accurate than Static Application Security Testing (SAST), for example.
This single list of security findings should include the following attributes:
- Severity Rating, should go beyond the tool-provided base (and temporal) metric-driven CVSS scores, and should take into account the organization’s unique environmental context. Examples include:
- Business criticality of the application
- How visible is the application or data stream to the public
- Data Classification/Sensitivity as defined by an organization’s policy. This goes beyond traditional Confidential/Secret/Top-Secret classifications. In today’s world, we also need to consider PII data restrictions, 3rd-party data sources and other sources of commercial or governmental data.
- Interconnectivity of the software – more widely used components have a larger attack surface area and potential impact. The Log4j vulnerability is an example of a very widely used component that could have a major potential impact on an application’s overall security.
- Age of discovery – The older the vulnerability, the bigger potential risk there is, as attackers have had more time to create an exploit.
- Date first reported, and required remediation date based on the Severity Rating defined above and Service Level Agreement (SLA) timelines.
- By providing a specific, clear due date (as opposed to a generic SLA ‘x-days’ time), engineering leaders can more quickly plan which sprint they will address the finding.
- Affected service, app, microservice, etc.
- Including the location of the finding, such as a source code repository or a monorepo path for SAST testing, and the API call or page URL for DAST testing, etc.
- Link to a JIRA story or similar tracking/project management system that has all details of the finding, including the information shared above, plus:
- How severity was calculated based on standard risk classification
- A direct link to the specific finding in the source tool’s dashboard if there are additional details that can help with analysis and research
- Clearly defined next steps for analysis, triage, and remediation, including a suggested fix
- A link to the relevant internal security standard/requirement
- Links to additional resources to assist with triage and remediation, such as an OWASP Cheat Sheet, the engineering team’s specific security support person, etc.
Here’s an example of the list:
Though we’ve focused on traditional appsec sources in this article, if engineering teams own other tool findings (IaC, containers, etc.), these findings should also be included in the list.
The road to clarity
Clearly outlining issues and requirements is an essential step in properly managing any AppSec program to effectively reduce security risk. Giving Engineering a clear road map and punch list of issues is necessary to properly engage and motivate them to take action. Framing it in the context of the project management tools, application sprint schedules and organizational priorities will help developers work security changes into their daily habits.
This isn’t easy. Several elements need to be established to achieve this level of clarity and build the foundation for a comprehensive view of potential threats. One such challenge is creating a central asset inventory system “data lake” or “data warehouse” that can be used to collect and relate the necessary data from a variety of sources. You can also use a product like Fivetran to assist with the extract, load, and transformation (ELT) of this data. Setting up a system like this will likely require involvement by more than just the security team – and the good news is that many of the best practices used to create this curated list for engineers can assist in managing an organization’s overall inventory needs. In other words, the work required to help prioritize security issues is also work that will help run the organization more efficiently overall.
As the President’s Executive Order on Improving the Nation’s Cybersecurity noted, “The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.”
Preparing for the unexpected will always be a challenge for security professionals and tracking the latest threats will often call for immediate action. If you maintain a current accounting of your systems and data streams, then when you find IoCs, you will know the potential points of weakness in your architecture, and what areas to protect immediately.
Better still, if you’re able to provide your engineering teams clear, actionable tasks in a format they can understand and integrate into their workflow, you may be able to prevent these attacks from happening in the first place. 
Dustin Lehr
Leave a Comment