Cybersecurity, Here to Help: Preventing Extra Cognitive Load for Developers
Cognitive load is one of the biggest challenges of software engineering that affects developers’ productivity and efficiency. Reif (2010) presents a highly insightful description of cognitive load: ‘The cognitive load involved in a task is the cognitive effort (or amount of information processing) required by a person to perform this task.’
Nowadays, developers face the challenge of handling intricate code, complex systems, CI/CD pipelines, multiple processes, and more. Furthermore, we expect them to manage compliance and security concerns effectively. Rather than piling on to the constantly increasing cognitive load problem, cybersecurity departments are responsible for alleviating it.
The shift-left approach to security reduces cognitive load by addressing potential issues as early as possible in the development lifecycle. Instead of retroactively tracing a vulnerability back through numerous layers of long-standing code, potentially crafted by a developer no longer part of the team, security risks are proactively identified and mitigated. By tackling problems when they are created or even before (while performing threat modeling), the shift-left strategy makes security issues less cognitively taxing and easier to resolve.
While beneficial, implementing the shift-left approach to security is challenging and can increase the cognitive load on developers if we do not do it correctly. For example, if we use a static analysis tool such as Semgrep, and it reports an error saying:
“Cannot determine what ‘$UNK’ is and it is used with a ‘<script>’ tag. This could be susceptible to cross-site scripting (XSS). Ensure ‘$UNK’ is not externally controlled, or sanitize this data.”
How will the developer know what cross-site scripting is? Especially if they didn’t have proper training. How will they know how critical this problem is or even if it is a real problem? And what is the best way of sanitizing the data?
The same can happen if CodeQL reports this problem:
“Making a network request to a URL that is partially user-controlled allows for request forgery attacks.”
What is a request forgery attack, and how do I properly avoid them?
Even vulnerabilities that might appear straightforward to a security specialist, like Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF), could paradoxically increase developers’ cognitive load. This happens when developers are expected to comprehend these vulnerabilities without sufficient context, support, or training, complicating the shift-left strategy.
Because of this, cybersecurity teams need to do more than design and deploy tools for a shift-left approach on the CI/CD pipeline. They should also understand vulnerability findings, interpret them, and guide developers to the most suitable solutions for each issue. Cybersecurity teams can significantly ease the developers’ cognitive load by serving as the bridge between complex security problems and practical solutions.
The cybersecurity team must communicate effectively to bridge complex security problems and practical solutions. This involves adopting strategies like providing clear, concise information, explaining the ‘why’ behind actions and the risks for the business (because it’s all about risks), offering illustrative examples, actively listening to concerns and queries, and tailoring messages depending on the developer and its expertise. With these principles in place, the cybersecurity team can ensure that security insights are understood and lead to appropriate and timely action.
In conclusion, to prevent extra cognitive burden for developers, cybersecurity teams must not only deploy tools for the shift-left approach but also provide clear explanations of vulnerabilities and solutions. By bridging the gap between complex security concerns and developer tasks, cybersecurity teams can make the shift-left strategy a value-adding process, promoting a more productive environment for software development.
