Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
News, news analysis, and commentary on the latest trends in cybersecurity technology.
What Building Application Security Into Shadow IT Looks Like
AppSec is hard for traditional software development, let alone citizen developers. So how did two people resolve 70,000 vulnerabilities in three months?
4 Min Read
Source: David Grossman / Alamy Stock Photo
Application security (AppSec) programs are difficult to use and filled with vulnerabilities. Overloaded staff face an inadequate budget. Communication with developers is challenging. These sayings are so true, so ubiquitous, that they've become tropes. This is why meeting a team of two who managed to resolve 70,000 security vulnerabilities in three months made me gasp.
70,000 Vulnerabilities? Really?
Actually, they found 80,000, 70,000 of which they were able to fix within 90 days. These numbers do not indicate particularly vulnerable applications. They indicate taking a real look in the mirror, beyond the usual lines drawn in the sand between professional development and citizen development, which we sometimes call shadow IT.
Citizen developers are now embedded in every part of large enterprises. Yes, that includes yours. Last year, Microsoft announced that Power Platform, its popular low-code/no-code platform built into M365, had surpassed 33 million users, growing 50% year over year. These users work for the enterprise — your enterprise. They build critical applications, from finance to risk and customer care. It's a real boost to digital transformation, for the business and by the business (user).
Citizen Development Security Challenges
A few aspects of citizen development make building an AppSec program around it particularly challenging:
The scale of citizen development is between 10x and 100x that of professional development, whether you measure it in terms of numbers of developers, number of applications, or any other metric.
The variance of business units can be so big that it is easier to think of some business units as separate entities. Indeed, in a large enough corporation, some business units fall under different laws and regulation and have a different risk appetite.
Citizen developers, as business users, are not security-savvy. If you try to explain injection attacks to a business user, it would probably not be a fruitful conversation or a good use of anyone's time. Citizen developers should do what they do best: move the business forward.
Finally, the lack of process can be tricky — citizen development is all about moving fast. You edit right in production, adapt quickly, and move forward.
Fortunately, some standards have emerged that document and categorize the security vulnerabilities in low-code/no-code apps built by citizen developers.
AppSec for Citizen Development
The good news is that the unique challenges of citizen development force us to think outside of the box. Any manual review or process goes out the window. Blocking business users from developing software is never a real option, even when we pretend it is.
Building a successful AppSec program for citizen developers requires heavy reliance on automation and self-service. We need to design a process, think about the edge cases, and automate it completely. For example, when a developer says they have fixed an issue, can you retest to confirm? Is there a clear route for escalation and asking for exemptions? What happens when service-level agreements (SLAs) aren't met? We have answers to all of these questions for traditional AppSec, relying on the software development life cycle and years of working with developers. Though none of the established processes work as is with citizen development, we can use our learnings from pro developers to design a solution that does.
To build your program, start with the basics:
Inventory. Know what you have, but don't stop there. Ask: Who is the owner for each app?
Policy. Clarify your risk appetite. Which applications are outside of your accepted use cases? Which should never have been built?
Security assessment and retesting. Know your risk, and have a way to automatically test whether this risk has been mitigated.
Self-service. Provide clear documentation. Create a self-service portal where citizen developers can learn about issues and how to fix them, where they can ask for clarification or exemptions.
Enforce SLAs. What happens if a vulnerability isn't fixed under an SLA? Take preventive action where possible.
Track and report. Ensure you get and maintain executive tailwinds by keeping everything informed on progress.
Management buy-in. Making progress at a fast pace requires strong tailwind from management. Clarify the security risk you are mitigating, and tell an enablement story rather than a blocking story.
The team I mentioned at the beginning of this article followed all of these points and more. They invested time in designing the process, down to its nooks and crannies. This gave them the confidence to hit "play" on the campaign and drastically reduce the security risk in their environment.
It's an incredible success — two employees, three months, 70,000 vulnerabilities, no business disruption. Those results may be exceptional, but you can achieve incredible results at your business as well.
About the Author
You May Also Like
More Insights