TL;DR: We’ve launched a free version of our Shadow IT scanner to identify which SaaS apps are used in your company, who uses them, and if they have high-risk OAuth scopes.
Philip and I went through YC with AccessOwl in 2022. We started the company because, in our previous roles, we struggled to track all the SaaS apps, users, and granted OAuth scopes. The Shadow IT scanner started as a small feature within AccessOwl, which manages SaaS vendors and user accounts centrally. But a standalone scanner would have made our lives so much easier in our previous roles. So, we thought, why not release it?
And here it is: a free, standalone Shadow IT scanner!
Hope you find it useful :) The Shadow IT scan helps with:
1. Offboarding: Employees often don’t report all the apps they sign up for, making it tough to track and secure these accounts when they leave, especially with the common SSO tax.
2. Security: OAuth scopes are quickly granted but rarely reviewed or removed, leading to organizations unknowingly spreading their data.
3. Compliance: Auditors need a list of SaaS vendors, which is hard to compile when employees sign up for tools independently.
Any surprises in your scan? What features would you like to see in the next version? Looking forward to your feedback!
FAQ
What’s Shadow IT? Unauthorized SaaS apps within an organization not centrally managed, posing security and compliance risks.
How does it work? Our tool connects to your Google Workspace or M365 instance, identifies OAuth tokens granted, and maps them to known SaaS tools. Note: In this v1 version, it only detects apps using the “Sign in with Google/Microsoft” button.
Who is this for? Typically IT and InfoSec teams, but in smaller companies, it may fall under the CTO.
Is it safe to use? Yes, reading OAuth tokens is standard for SaaS management tools. Data extraction only occurs when you initiate a scan. AccessOwl is SOC 2 Type II audited and GDPR compliant.
On the one hand, such a rule sounds like stodgy company friction to "getting it done".
On the other hand, I see employees putting crucial information across seemingly every SaaS they'd heard of, except for the official place it's actually supposed to go. Making it inaccessible to the people who needed it, and often eventually losing the information entirely.
I've also seen (to pick one anecdote) newer software developers pasting the data of a very sensitive proprietary engineering model into some random developer's Web site that provided a visualization. This random Web site then spread around engineering as the standard way you visualize that model.
And I've seen third-party service dependencies that made no sense at all, but people were just following tutorials and StackOverflow answers they found.
It also comes down to appropriate procurement processes. Employees should not be able to buy or procure anything without requiring them to assess the inherent risks that service will introduce. Those risks include the cyber/information security related risks of that service including SaaS platforms.
You should not be able to purchase an use any technology service without a risk assessment and that includes SaaS platforms, to identify if the information you're providing to that platform is secure.
Slack and Loom are great examples of SaaS that profited from being "Shadow IT". They gained traction by employee's quickly self-onboarding onto the free-plan, without their IT or Security knowing what data is being shared.
I feel not blocking makes most sense. Employee's want to be treated like adults, especially in tech savvy companies. If they feel like they are unnecessarily blocked they will just find a workaround (i.e. non-work email or device).
However, you definitely want to keep track of people are signing up for - that's where the Shadow IT scanner comes in handy. In case you see something that's against policy it's often enough to just explain why it's a risk for the company. No employee means harm and just wants to be treated like an adult.
But it is helpful to block certain things that are just too common outside of work so people just don't think twice. Things like ChatGPT, Grammerly, Pastebin, etc. should be manually blocked.
Any company that is reigning in SaaSes is doing so because they have had a bad experience. If you have this privilege, that's cool, but be smart about it. Make a unique account for your business use rather than comingling your personal data, and choose SaaS companies who you would actually be okay having a relationship with, because the relationship WILL get escalated and wouldn't it be nice if it were a cool HN person making the pitch instead of Oracle mailing you an extortion letter?
One of my clients, we had been trying to sell them on corporate groupware instead of personal dropboxes and gmails. The hammer dropped when they got sued and guess what got specified in the evidence search? Not only was executing that search deeply unpleasant for everyone involved, but it also cost a lot more consulting hours than searching a proper groupware would.
It's not like you have to have a lot of red tape around signing up for SaaSes. "Any employee can sign up for one, you just have to notify us" or "Approval is practically a rubber stamp" is waaaay better than "who knows what they're doing" -- at least you know what's happening and can deal with it later
Every company bigger than 100 people I've been at covers this in the corporate training on the first week. You can't just put the company's data into random textboxes on the internet. And you can't pretend you weren't told. This is how to get fired immediately anywhere with a clue.
Even at a startup, the process could be reaching out to the "CTO" on Slack for 30 seconds. Nobody should just be doing stuff like this with zero oversight, ever, anywhere, unless just none of it really matters, like some sort of complete joke app like something to rate the attractiveness of your college classmates or something
https://www.accessowl.io/pricing
How does pricing work if Slack is not used?
This does seem like a weird restriction. Nothing about the product otherwise seems Slack-specific.
What do you use instead?
Core aspects of the product like workflows and task management should not be tied to a chat vendor in my opinion, and would make me extremely nervous as a potential buyer due to your complete dependence on what SF does with Slack.
I’ve also worked places that strongly dislike Slack and won’t touch it since it was acquired by Salesforce. Ironically, your product would cause Shadow IT deployments (of Slack) in such environments.
Sharing these concerns because I think the product is a really useful concept, but your roadmap for these core functions would mean the difference between considering and completely passing over AccessOwl, i.e. for some subset of potential customers, the hard dependency on Slack is a complete blocker.
This was helpful because it would detect SaaS platforms being used that were not integrated into SSO, like PDF converters etc
But I really like how simple this looks to use and it looks powerful
Great work guys!
https://www.courseplatformsreview.com/wp-content/uploads/202...
Dead Comment