# Sola Security > Get Security Done --- ## Pages - [Roadmap](https://sola.security/roadmap/): Sola's roadmap is driven by our community of cyber security tool builders. Got an idea? Leave feedback or make a suggestion, we're listening. - [DPA](https://sola.security/dpa/): Effective / updated March 6, 2025 Applicability. This Data Processing Addendum (“DPA”) is incorporated by reference into the Sola Security... - [Pricing](https://sola.security/pricing/): Sola is bringing affordability to the cyber security space. We’re starting with a completely free product for everyone who uses it. - [Overview](https://sola.security/overview/): Create custom security apps with Sola. Tackle any security question, big or small, and download or build the solution your really need. - [Accessibility](https://sola.security/accessibility/): Last updated: January 23, 2025 At Sola Security, we are committed to ensuring that our digital space is accessible to... - [Terms & Conditions](https://sola.security/terms-conditions/): Last Updated: March 9, 2025 These terms of service (the “Terms”) are a legal contract between Sola Security Inc. and... - [Integrations](https://sola.security/integrations/): Build amazing security apps by integrating Sola with your existing stack and data sources. Check out our integrations directory. - [Careers](https://sola.security/careers/): We’re not your typical cybersecurity company: we're making cyber security accessible for everyone, and you can join our mission. - [About](https://sola.security/about/): We're making cyber security more accessible, simple and affordable for anyone. Get security done without jumping through a thousand hoops. - [Home](https://sola.security/): Get security done with Sola: Create custom security apps to fit your exact needs, faster, with AI built for security. Start now for free. - [Privacy Policy](https://sola.security/privacy-policy/): Effective Date: March 6, 2025 Sola Security Inc. , its affiliates, and subsidiaries (“Sola” “we,” “our,” or “us”) values your... --- ## Apps --- ## Integrations - [Google Workspace](https://sola.security/integrations/google-workspace/): Connect your Google Workspace account to Sola to uncover how documents are shared in your organization and enforce policies. - [MongoDB Atlas](https://sola.security/integrations/mongodb-atlas/): Build security apps with custom alerts and canvases in minutes for MongoDB. Get cloud security done with Sola. - [Google Cloud Platform](https://sola.security/integrations/gcp/): Connect your Google Cloud Platform account to your Sola workspace to explore your data and build custom security apps. - [GitHub](https://sola.security/integrations/github/): Build security apps with custom alerts and canvases in minutes for your GitHub account. Get security done with Sola. - [Okta](https://sola.security/integrations/okta/): Connect your Okta admin account to your Sola workspace to gain full visibility into authentication statuses and streamline SSO adoption. - [Wiz](https://sola.security/integrations/wiz/): Connect your Wiz Cloud Security Platform account to your Sola workspace to explore your data and build custom security apps. - [Azure](https://sola.security/integrations/azure/): Connect your Microsoft Azure account to your Sola workspace to explore your data and build custom security apps. - [AWS](https://sola.security/integrations/aws/): Build security apps with custom alerts and canvases in minutes for your AWS cloud environment. Get cloud security done with Sola. --- ## Newsroom --- ## Press release - [Sola Security Emerges from Stealth with $30M to Democratize Cybersecurity](https://sola.security/press-release/sola-security-emerges-from-stealth/): The no-code, AI-powered Canva for cybersecurity, lets security teams of any size build custom solutions in minutes, without the enterprise price tag --- ## Roadmap items - [Email notification for alerts](https://sola.security/roadmap-item/email-notification-for-alerts/): Get notified by email when an alert is triggered in your app. - [OpenAI Integration](https://sola.security/roadmap-item/openai-integration/): Connect your OpenAI account to your Sola workspace to get security insights on users, projects, API keys, audit logs and... - [Slack connector for Sola AI](https://sola.security/roadmap-item/slack-connector-for-sola-ai/): Extend Sola AI’s capabilities to perform a variety of tasks directly within your Slack, such as automatically sending a Slack... - [Jira connector for Sola AI](https://sola.security/roadmap-item/jira-connector-for-sola-ai/): Extend Sola AI’s capabilities to perform a variety of tasks directly within Jira, such as automatically creating a Jira ticket... --- ## Questions - [How to check Azure managed identity assignments](https://sola.security/questions-hub/azure-managed-identity-check-assignments/): Learn how to check Azure managed identity assignments with best practices for Azure security and Azure compliance. Start now with Sola. - [How to find MongoDB clusters missing IP whitelists?](https://sola.security/questions-hub/mongodb-ip-whitelists-how-to-find/): Find MongoDB clusters missing IP whitelists fast. Improve MongoDB security and database security with direct visibility via Sola. - [How to monitor security risks across cloud accounts?](https://sola.security/questions-hub/cloud-security-monitoring-across-accounts/): Cloud security monitoring made easy—get visibility into cloud security posture and cloud threat detection in minutes with Sola. - [How to detect GitHub API tokens in code?](https://sola.security/questions-hub/how-to-detect-github-api-tokens-code-security/): Learn how to detect GitHub API tokens in code and improve GitHub security and secrets access with better posture. - [How to monitor GitHub production deployments?](https://sola.security/questions-hub/how-to-monitor-github-actions-production-deployments/): Learn how to monitor GitHub actions deployment securely. Use Sola to audit GitHub deployments and harden your GitHub security posture fast. - [How to identify overexposed Drive files by user](https://sola.security/questions-hub/how-to-identify-overexposed-drive-files-by-user/): Learn how to audit google drive file sharing risks by user and boost Google Workspace security with practical steps. - [How can I inventory shared Drive files that contain sensitive data?](https://sola.security/questions-hub/how-to-inventory-shared-files-sensitive-google-workspace-drive/): Google Drive data protection made easy. Learn how to boost Google Workspace security and find sensitive file shares in minutes. - [How to audit file sharing across Google Workspace?](https://sola.security/questions-hub/how-to-audit-file-sharing-google-workspace/): Learn how to use Google Drive access control for secure file sharing compliance and improve your Google Workspace security posture. - [How to find Okta users without MFA?](https://sola.security/questions-hub/how-to-find-okta-users-without-mfa/): Learn how to check Okta MFA enrollment status and find users without Okta multi-factor authentication using the Okta user list - with Sola's help. - [Is my RDS instance publicly accessible?](https://sola.security/questions-hub/is-my-rds-instance-publicly-accessible-aws/): Learn how to check RDS public access and improve AWS network security and AWS public access controls with better visibility. - [How to track GitHub deployments without CI/CD pipelines?](https://sola.security/questions-hub/how-to-track-github-deployments-without-ci-cd-pipelines/): Meta description: Learn how to track GitHub deployments without a CI/CD pipeline while improving GitHub repository security and visibility. - [How to monitor GCP audit logs for compliance?](https://sola.security/questions-hub/how-to-monitor-gcp-audit-logs-for-compliance/): Learn how to monitor GCP audit logs for GCP compliance and cloud security compliance. Ensure visibility, alerts, and action with ease. - [How to enforce VPC endpoint policies in AWS?](https://sola.security/questions-hub/how-to-enforce-vpc-endpoint-policies-in-aws/): Learn how to enforce a VPC endpoint policy for AWS S3 buckets and improve your AWS security posture with minimal effort. - [How to check GitHub repo branch protection?](https://sola.security/questions-hub/how-to-check-github-repo-branch-protection/): Learn how to check GitHub branch protection for better GitHub security and compliance—plus how to automate it with Sola. - [How to secure AWS API gateway?](https://sola.security/questions-hub/how-to-secure-aws-api-gateway/): Learn AWS security basics for API gateways. Get best practices, use AWS Inspector, and run an AWS security audit. - [Cyber security for startups: Where to Start?](https://sola.security/questions-hub/cyber-security-for-startups-where-to-start/): 5 Key Security Best practices for Startups: Lock down your cloud: Cloud security for startups begins with cleaning up AWS.... --- # # Detailed Content ## Pages Effective / updated March 6, 2025 Applicability. This Data Processing Addendum (“DPA”) is incorporated by reference into the Sola Security Terms of Service and/or any other agreement governing the use of Sola’s services ("Agreement") entered by and between Sola Security Inc. , and its affiliates ("Sola") and you, the User (as defined in the Agreement), and for purposes of this DPA shall be referred to as (the "Client"), to the extent that Sola processes Personal Data (as defined below) solely on behalf of Client.  By signing the DPA, and/or accepting the Agreement, and/or accessing and/or using the Services (as defined in the Agreement), Client accepts this DPA, and if the person signing or accepting or clicking through to the Services is entering the DPA on behalf of another entity or person, such person hereby represents and warrants to Sola that such person is authorized to bind Client to this DPA through such consent or use of the Services. If such person does not have such authority or if Client does not agree to this DPA, please do not provide Personal Data to Sola. Definitions. Terms used in this DPA but not defined herein (whether or not capitalized) shall have the meanings assigned to such terms in the Applicable Data Protection Laws or the Agreement. “Applicable Data Protection Laws” shall mean, to the extent applicable to Sola's processing of Personal Data hereunder (with respect to each data subject): (i) General Data Protection Regulations (European Parliament and Council of European Union (2016)... --- Last updated: January 23, 2025 At Sola Security, we are committed to ensuring that our digital space is accessible to all individuals, including those with disabilities. We continuously work to improve accessibility across our website and to provide an inclusive experience for all visitors, employees, and users.   Our website has been designed to adhere as closely as possible to the principals of the Web Content Accessibility Guidelines (WCAG) 2. 1 AA – a recognized global standard for web accessibility, and with the accessibility standards set forth in the Israeli Standard (IS 5568) for internet content accessibility, which is based on WCAG 2. 1 AA.   Our website accessibility features include (but are not limited to): Keyboard navigation support Screen reader support. Alternative text for images as needed. Zoom in support using browser controls High-contrast design. Closed captions and transcripts for multimedia content. Error correction support. Feedback and Assistance We welcome your feedback on the accessibility of our website. If you encounter any barriers, have suggestions for improvement, or require assistance or accommodation, please contact our Accessibility Manager Ron Peled at e-mail: accessibility@sola. security. We have a dedicated Accessibility Manager at the company and we aim to respond to accessibility-related inquiries within 5 business days. We value your input and are committed to ensuring an accessible and inclusive experience across all aspects of our organization. Thank you for helping us improve! --- Last Updated: March 9, 2025 These terms of service (the “Terms”) are a legal contract between Sola Security Inc. and its affiliates (“Company”, “we” or “us”) and “you” (“Participant”, “your”, or “User”). The Terms explain how you are permitted to use the services provided by and through our web-based platform and virtual properties (main URL located at https://app. sola. security/) as well as all of our associated websites and/or online properties (either linked by Company and/or by our affiliated companies) and any cloud and downloadable software applications, plugins or extensions that Company provides to you for download or use, including in your mobile devices (collectively, the “Sola App(s)”) (all of these virtual properties, software and mobile applications, collectively, the “Site”). These Terms also govern your use of all the text, data, information, software, graphics, proprietary content, documentation (including our application programming interfaces (“API”)) and more (all of which we refer to as “Materials”) that we and/or our affiliates may make available to you, as well as any services we may provide through this Site. Collectively, the Site, the Materials, and the services provided therein are referred to as the “Services. ” BY AGREEING TO THESE TERMS, OR BY ACCESSING, REGISTERING IN, CREATING AN ACCOUNT, MAKING PURCHASES, DOWNLOADING, ACCESSING, OR USING OUR APPS, PROVIDING INFORMATION THROUGH, OR GENERALLY USING THE SERVICES, YOU INDICATE THAT YOU HAVE BOTH READ AND ACCEPT THESE TERMS. IF YOU DO NOT AGREE WITH ANY OF THESE TERMS, DO NOT ACCESS OR OTHERWISE USE THE SERVICES OR... --- Effective Date: March 6, 2025 Sola Security Inc. , its affiliates, and subsidiaries (“Sola” “we,” “our,” or “us”) values your privacy. This Privacy Policy (“Policy”) describes how Sola collects, uses, discloses, and otherwise processes personal information described in this Policy, as well as the rights and choices individuals may have regarding such personal information. For additional information about the privacy choices you may have regarding your personal information, please review the Your Privacy Choices section below.   By using our Services (as defined below), you agree that your personal information will be handled as described in this Policy. Your use of our Services and any dispute over privacy, is subject to this Policy and our Terms and Conditions, including their applicable terms governing limitations on damages and the resolution of disputes. Table of Contents 1. Scope 2. Personal Information Collected 3. How We May Use Personal Information 4. Disclosures of Personal Information 5. Cookies and Other Tracking Mechanisms 6. Your Privacy Choices 7. External Links and Features 8. User Generated Content 9. Children’s Privacy 10. Security 11. Changes to this Policy 12. Contact Us ScopeExcept as otherwise described below, this Policy applies to our online personal information processing activities including, but not limited to: visitors to our website where this Policy is posted, including https://sola. security (the “Site”); individuals who sign up for, or create an account with us to access and use our platform available at https://app. sola. security; individuals who register for or participate in our events, surveys,... --- --- ## Apps ## Apps --- ## Integrations --- ## Newsroom --- ## Press release – Sola Security, the self-serve platform built to democratize cybersecurity, announced its launch from stealth today with a $30 million seed round led by S Capital and veteran venture capitalist Mike Moritz. Investors also include S32, Glilot Capital Partners, and several prominent angel investors. Sola Security is redefining how organizations build and deploy security tools by eliminating complexity, cutting costs, and putting power back into the hands of security professionals at every level, enabling them to create tailored solutions with its no-code, AI-powered platform. Founded in 2024 by cybersecurity veterans Guy Flechter (former CEO & Co-Founder of Cider Security, acquired by Palo Alto Networks) and Ron Peled (former Global CISO of LivePerson and strategic security consultant to startups), Sola was born from frustration with the industry’s current model: security teams drowning in expensive, siloed tools that require dedicated engineering resources to manage. Organizations today juggle up to 50 separate security tools, each with its own UI, costs, and maintenance headaches. Smaller teams and solo security professionals struggle even more, lacking the resources to manage bloated security stacks. The result? A landscape of inefficiencies, security gaps, and wasted budgets. Sola Security lets businesses build functional security apps from start to finish, without needing deep technical expertise or bloated budgets. Users can deploy ready-made security tools from the Sola App Gallery or build custom security solutions using Sola’s AI-powered no-code studio. “Cybersecurity shouldn’t be this hard or expensive. That’s the challenge Sola Security is here to solve” said Guy Flechter, CEO &... --- --- ## Roadmap items Get notified by email when an alert is triggered in your app. --- Connect your OpenAI account to your Sola workspace to get security insights on users, projects, API keys, audit logs and more. --- Extend Sola AI’s capabilities to perform a variety of tasks directly within your Slack, such as automatically sending a Slack message when a specific alert is triggered. --- Extend Sola AI’s capabilities to perform a variety of tasks directly within Jira, such as automatically creating a Jira ticket when a specific alert is triggered. --- --- ## Questions Best practice: Comprehensive inventory and scope Analysis The first step in managing Azure managed identity assignments effectively is building a comprehensive inventory. You need complete visibility into every Azure resource - whether it's virtual machines, app services, logic apps, or functions - that uses a managed identity. Tools like Azure CLI (az identity list) and Azure Resource Graph can assist here. Once you’ve mapped out all assignments, perform a thorough privilege and scope analysis. Highlight identities with elevated privileges, especially those assigned roles like Owner or Contributor at subscription or resource-group levels. These broad permissions are typically unnecessary and a common compliance issue. Strategy: Detect over-privileged and inactive identities Regularly detecting over-privileged and unused identities is critical. Identities granted excessive privileges can become attack vectors, especially when left unused and forgotten for extended periods. Identify any identity not used in the last 90 days and those assigned permissions beyond their functional need. With automated detection, you can flag and remediate these identities quickly, significantly reducing security exposure and ensuring ongoing compliance with Azure security best practices. Tips: Enforce least-privilege and track changes Maintaining least-privilege access, assigning identities only the permissions required, is fundamental. Always prefer Reader or tailored custom roles over broader ones like Contributor. Monitor monthly changes and role assignments to detect privilege creep early. Because let’s be honest: “temporary” Contributor access never stays temporary. If you’re not watching for scope creep, you’re basically inviting it in for coffee. Staying vigilant prevents unauthorized access and aligns your practices closely... --- Don’t audit security manually. Manually checking each cluster’s IP access list in MongoDB Atlas doesn’t scale. Most teams don’t even realize how many test environments or forgotten clusters are wide open. The quickest path to visibility is querying the configuration directly and flagging anything that allows unrestricted access. In Sola, you can use the MongoDB Security Compliance App to surface exactly that, across all projects and environments. Just connect your data source, and the app shows you which clusters skipped IP restrictions. What to look for in your IP access rules Your query should return clusters where: ipAccessList is null or empty One or more entries match 0. 0. 0. 0/0 The access list doesn’t exist (for self-managed deployments) This tells you which clusters have no network boundary in place — one of the most basic MongoDB security best practices. If you’re using Terraform or other config-as-code tools, it’s worth checking those too. Build your own MongoDB security view Whether you start with the MongoDB Security Compliance App or decide to create a new one from scratch, Sola still lets you move faster. Use the AI co-pilot to define your check in plain language, plug in the relevant data, and get immediate visibility, without sifting through cluster settings one by one. --- What does good cloud security monitoring actually look like? It’s not just a dashboard or another log aggregation UI. It’s a continuous check of the actual risks that matter, across every cloud account. Here are the basic four legs you should look for in your cloud security posture solution: IAM issues: Users without MFA, roles with wildcards, or service accounts that haven’t been touched in months, but still have access to prod. Storage exposures: That “temporary” public S3 bucket which could still be public, and now it has sensitive data. Network risks: Security groups with 0. 0. 0. 0/0 inbound rules, or forgotten firewalls that allow SSH from anywhere. Drift over time: A new service account gets created. Someone spins up a public IP. You didn’t authorize it, but now you know. Now, multiply that across all cloud accounts, and get them in one place. Sounds like a three-week project to build it, but with Sola, it would take you minutes. Best practices: Monitor what actually matters Start with misconfigurations, not vulnerabilities: CSPM tools love to drown you in CVEs. But most breaches don’t start with an exploit, they start with bad config. Focus on wide-open ports, over-permissive IAM, and exposed storage. These are quite easy to fix and high risk. Go multi-cloud, or go blind: Many teams end up with workloads spread across AWS, GCP, and Azure, not always because of some grand multi-cloud strategy, but because someone needed a service fast and defaulted to whatever was easiest or... --- Common detection strategies and why they fall short The textbook method? Regular expressions. You scan your codebase (or CI pipeline) for token formats: GitHub tokens usually start with ghp_, gho_, ghu_, or ghs_ depending on the type. GitHub even has token scanning built in, but it’s limited to public repos unless you explicitly enable it for private ones. You can also plug in tools like truffleHog, Gitleaks, or custom pre-commit hooks. But you’ll quickly hit a wall: Noise: you're likely to get loads of false-positives. Context: such tools are usually blind to context, like whether the token is active, or if it has dangerous scopes. Afterthought: they're reactive, and not preventive. And once you find a token, what next? Most setups lack remediation steps, visualization for stakeholders, or any way to track whether secrets are creeping back in. Detection alone doesn’t cut it. Building continuous posture checks with Sola AI Instead of manually string-scanning for GitHub access slip ups, you can build your own token exposure detector in Sola, using our AI agent. Alternatively, you can install this GitHub Security Posture app, connect your org, and get immediate insights: Where are API tokens exposed? What scopes do they carry? Who has access, and how risky is it? You define the queries, such as “show me all secrets in code with write:org scope”, and Sola gives you answers instantly. Then visualize it for your team or set up alerts to keep the noise down and the impact high. Your codebase isn't... --- Secure GitHub deployments start with visibility If you’re using GitHub Actions to push to production, you need to know exactly which workflows are doing what, and who has the keys. That means more than just skimming the Actions tab, because the defaults aren't good enough. You should be auditing: Which repositories have deployment permissions Which environments are being used (and how they’re configured) Who has access to modify workflows and trigger deployments Start with GitHub’s deployment history, but don’t stop there. You need structured visibility: who ran a deploy, what was deployed, and whether the right guardrails were enforced. Deployment logs won’t tell you if someone quietly disabled branch protection or introduced a rogue workflow file with push access. This is exactly where Sola’s GitHub Security Posture app comes in. Plug it into your GitHub org and get a clear view of deployment permissions, access levels, and risky configurations—without writing custom scripts or crawling APIs manually. Everything’s mapped, alertable, and customizable. Best practices for GitHub deployment security GitHub security is less about luck and more about hardening what’s already there: Use OIDC tokens instead of long-lived secrets Make environments required for production, with manual approvals and reviewers Enable deployment protection rules to gate sensitive workflows Lock down the GITHUB_TOKEN with least privilege You could script all this, or let Sola show you where you’re exposed and act on it directly from your dashboard. Secure GitHub deployments start with visibility In Sola, you can build a custom security app that gives... --- The root problem: Google Drive sharing is... too easy Google made Drive file sharing frictionless, which is great for productivity, but a bit of a nightmare for Google Drive security. Most overexposure happens through public links or “anyone with the link” sharing, often done unknowingly. The result: sensitive files floating around without control, often undetected until it’s too late. Unfortunately, Google’s native audit tools only take you so far. The Alert Center, DLP rules, and Drive audit logs can help, but they require setup, filtering, and still won’t give you that clean “Show me all files this user shared externally” view. Use Google Drive audit logs, but don’t stop there You can identify overexposed files by user in Google Workspace, but it takes effort. Use the Drive audit logs in the Admin Console to filter for external shares, and pivot by actor. This gives you visibility into who’s sharing externally and what files are involved. To go further, export logs to BigQuery or connect them to a SIEM. Still, this approach is bulky, not real-time, and demands scripting or third-party tooling. Use Sola to answer that question instantly Sola offers a faster way to find out overexposed files by user. In your Sola Workspace, grab the Google Workspace - Publicly Shared Files Insights app, or build your own with the AI co-pilot. Connect your Google data source, and in minutes, get a clean breakdown of users, their externally shared files, and alert conditions you actually care about. Quite simply, Google... --- Why Google Drive is a minefield for sensitive data Google Drive security suffers from one core issue: oversharing is default, not the exception. Whether it's the "Anyone with the link" setting, third-party app syncs, or just good old-fashioned carelessness, sensitive documents regularly end up exposed beyond intended audiences. Companies share thousands of file externally each month, most of which go completely untracked by anyone within the organization. Add in things like spreadsheets with unredacted PII or contracts floating in shared drives, and it becomes a full-blown sensitive data protection mess. Google Workspace security best practices suggest tightening sharing settings and regularly reviewing access. But let’s be honest here: manual audits don’t scale, as teams don't have the bandwidth. You need automation and customization that adapts to your actual risks. Best practices for Google Workspace data inventory Automate access reviews: Build or deploy a solution that automatically inventories shared files and flags those shared externally or with “Anyone with the link. ” Tag sensitive data: Use DLP or custom logic to tag files containing PII, financials, legal documents, etc. Bonus points if you link that tagging to risk-based alerts. Enable least privilege sharing: Enforce domain-based sharing and strip public links. If your security tooling can’t help you do that, it’s probably not helping at all. Implementation: no need to waste on vendors. Google doesn’t give you a great native way to inventory and classify shared files. Security vendors will try to upsell you on “enterprise-grade” tools bloated with dashboards you’ll never... --- Understand your native tools Google Workspace offers two built-in tools to monitor file sharing: the Audit and Investigation Tool, and the Security Investigation Tool. These let you track drive activity logs, filter by user or event type, and export reports. Sounds fine on paper, until you try to figure out which files are publicly exposed or shared with external domains. You’ll find yourself exporting CSVs and manually sifting through logs. Not ideal. For organizations that want Google Workspace security without babysitting spreadsheets, this isn’t sustainable. Compliance isn’t just about having logs, it’s about continuously being able to prove you're not sharing sensitive files with the wrong people. The native tools just weren’t built for that. Google Drive access control best practices Start by disabling public link sharing by default and restricting sharing to trusted domains. Enable DLP (Data Loss Prevention) to scan for sensitive content before it leaves your org. Enforce MFA across all accounts, and turn on context-aware access policies. Next, automate detection of risky sharing behaviors. This includes files shared with personal Gmail accounts, external domains that aren't partners, or "Anyone with the link" permissions. Spoiler: This is where Sola’s Google Workspace Files App comes in. You can deploy it in seconds and immediately surface issues like public links or external shares without building a thing. Want to go deeper? Build your own auditing app with Sola's AI capabilities to answer specific compliance questions. Either way, google drive access control gets a lot easier when you're the one... --- Instead of drowning in audit logs or clicking endlessly in the admin console, just build your own view with Sola’s Access Control Okta Insights app. Plug in your Okta instance, define your question like “show me all users who haven’t enrolled in MFA” using our AI agent, and the answer is right there. You can even customize it further to get more clarity. Understand your Okta user list and permissions Okta’s user management model gives super admins the power to view MFA enrollment across all users, but you need to know where to look. You can start from the Admin Console under Reports > Authentication > MFA Enrollment. Here, you can export a list showing who’s in and who’s out. Want to go deeper? Use Okta’s API (/api/v1/users) to fetch the Okta user list, then correlate it with the factor enrollment endpoint (/api/v1/users/${userId}/factors). This lets you programmatically sift out users without any enrolled factor. Pro tip: Watch out for users with no assigned apps. They often fall through the cracks when enforcing MFA. And remember: not all admins are created equal. You need super admin permissions to see the full picture. Implementation tips: Don’t just enforce, monitor Enforcing MFA isn’t a one-time deal. People leave, roles change, new apps get added. Make sure your process includes regular reviews of MFA status, especially for privileged users. Automate it if you can (hint: Sola can help). Integrate checks into your access management flow. Before granting new permissions or app access, validate MFA... --- RDS public access: understanding the risks When RDS public access is enabled, your database is reachable over the internet—great for testing, disastrous for production. This isn’t just bad practice; it’s a compliance red flag, and in some industries, it’s a full-blown violation. AWS itself doesn’t prevent you from misconfiguring public access. It gives you the tools (like VPC settings, subnet visibility, security groups, and NACLs), but it’s entirely on you to get them right. A common misconception is that setting PubliclyAccessible=true is enough. It is not. Your database also needs to be in a public subnet, with open security group rules and an internet gateway. How to check RDS public access - and how to lock it down Start with these basics: In the RDS console or via CLI, check PubliclyAccessible status. Audit the VPC subnet’s route tables and see if it routes through an Internet Gateway. Confirm that security groups don’t allow unrestricted ingress (e. g. , 0. 0. 0. 0/0 on port 5432 or 3306). For a real-world-ready solution, use a tool like Sola to continuously check that no RDS instance gets deployed publicly without a reason - and without someone knowing. Alternatively, you can just use AWS Config. Best practices for AWS network security and compliance When RDS public access is enabled, your database is reachable over the internet—great for testing, disastrous for production. This isn’t just bad practice; it’s a compliance red flag, and in some industries, it’s a full-blown violation. AWS itself doesn’t prevent you... --- GitHub gives you deployment history, but not context GitHub’s deployment tracking doesn’t require a pipeline. You can manually post deployment records via API or script. These can be tied to specific commits, environments, and users. You also get deployment status events, which help track whether something actually made it to production. But here’s the catch: this shows what happened, not whether it was a good idea. You won’t know if a deploy bypassed review policies, introduced secrets, or came from an unverified source. That’s the missing piece - GitHub repository security without CI/CD needs more than logs. It needs correlation and interpretation. With Sola, you can connect deployment events to audit logs, code changes, and user behavior. You’ll know if a deploy happened outside working hours, if the committer wasn’t the deployer, or if sensitive files were touched. And if something smells off—you’ll get an alert. Keep your GitHub secure even without full automation Even if you’re not running CI/CD, GitHub repository security basics still apply: Lock down branches with protection rules and reviews Rotate deploy keys and enforce secret scanning Restrict access to the minimal set of users and tokens Track push and deployment activity, even if it’s “just a script”. Sola’s GitHub Security Activity app helps you monitor these without writing policy as code or building a full pipeline. It gives you the insights and alerts you actually care about, based on your real workflows. You can build a custom app to track deploys, correlate actions, and decide... --- Best practices for monitoring GCP audit logs GCP audit logs are split into three types: Admin Activity, Data Access, and System Event logs. For cloud security compliance, you need visibility across all of them. Here’s how to do it right: Enable all audit log types: By default, only Admin Activity logs are enabled. You’ll need to explicitly turn on Data Access logs, especially for tracking read operations on sensitive data. Use Log Sinks to centralize: Route logs to Cloud Logging, BigQuery, or external SIEMs. Without a centralized logging strategy, your chances of passing a compliance audit? Slim. Set up meaningful alerts: No, not every API call needs an alert. But access to a sensitive resource outside of working hours? Absolutely. With Sola, you can define these questions directly in your workspace. “Alert me if a new service account is created with owner privileges. ” Done. You don’t need to reverse-engineer compliance from scratch. Implementation strategies that won’t burn cycles Getting from log collection to GCP security insights requires more than dumping logs into BigQuery. Start with: Pre-built dashboards: GCP provides basic visibility, but they aren’t tailored to compliance needs. You’ll want to customize them, or just use a Sola app that already does. Retention policies: Most audit logs are retained for 30 days. If you’re targeting GCP SOC 2 compliance, configure longer retention in Cloud Logging or export to storage buckets. Access control: Only specific roles should access logs. Use IAM to lock it down and monitor who views what.... --- Understand the VPC Endpoint Policy Basics When using a VPC endpoint for S3, the first trap people fall into is assuming it's “private, so it’s safe. ” Not quite. Without a VPC endpoint policy, anyone with network access to the VPC can hit S3 (assuming their IAM role allows it). Endpoint policies give you an additional access control layer that enforces “who can use this VPC endpoint to talk to this service. ” The policy syntax is similar to standard IAM policies. You define actions, resources, and principals, but scoped to what goes through the endpoint. For example, you might allow only a specific IAM role to access a particular S3 bucket via a given endpoint, and deny everything else. The key is: the endpoint policy only affects traffic through the endpoint, it won’t stop access over the public internet, unless your bucket policy also enforces aws:SourceVpce. Best Practices for Enforcing Endpoint Policies Use explicit denies for anything you absolutely want to block. IAM allows are permissive by default. Combine with S3 bucket policies to restrict access based on the aws:SourceVpce condition key. This ensures that even if a user has access, they must go through the intended VPC endpoint. Avoid overly broad permissions—limit access to exact actions (e. g. s3:GetObject) and specific resources. Test using IAM Policy Simulator or CloudTrail logs to validate that your endpoint policy behaves as expected. Tag your VPC endpoints and enforce tagging policies via SCPs or automation if you're running multi-account setups. Don't just... --- Best Practices for GitHub Branch Protection GitHub branch protection rules are your front line of defense. At a minimum, you should enforce: Required pull request reviews before merging. Status checks to ensure tests pass. Push restrictions to prevent direct commits to protected branches. Required signed commits for auditability. No force pushes or deletions on main/release branches. That’s your GitHub compliance starter pack right there. These settings block most of the stupid mistakes that turn into production incidents or security audits from hell. If you're not enforcing these org-wide, you’re probably flying blind. How to Check Branch Protection at Scale For one-off checks, go to your repo on GitHub, then: Click Settings → Branches Under "Branch protection rules", select the branch Review the applied settings (pull reviews, checks, etc. ) For multiple repos, the GitHub REST API (/repos/{owner}/{repo}/branches/{branch}/protection) is your friend. Or just skip the scripts and use Sola: build an app that shows protection status across all branches and repos, flags violations, and lets you take action without leaving your workspace. With the GitHub Security Posture App, you can monitor protection status across all branches and repos, flag gaps, and even create alerts. Customize it however you like. Yes, even your weird branching strategy. --- Want to know which APIs are actually unsecured? Most teams think their API Gateway is locked down, until someone runs a check and finds unauthenticated endpoints open to the internet. Securing AWS API Gateway isn’t just about setting policies; it’s about knowing what’s actually live, what’s exposed, and what’s misconfigured. You need answers to questions like: Which endpoints are public and unauthenticated? Are rate limits and throttling really in place? What methods are exposed without protection? Connect your cloud account to Sola, define these questions, and instantly surface the answers. No code, no guesswork. AWS Security Best Practices for API Gateway Auth Everything: IAM for internal access, Cognito or JWTs for users, custom authorizers if needed. No public APIs unless they’re read-only and harmless. Throttle by Default: Set sensible limits to avoid DDoS-by-misuse. Even trusted clients mess up. Log All Requests: Use CloudWatch Logs and AWS X-Ray. It's your only trail when things go sideways. Attach WAF: Protect against injection attacks, bots, and other low-effort exploit attempts. Audit Frequently: Use AWS Inspector and IAM Access Analyzer. If you’re not auditing, you’re guessing. Implementation Tips That Matter Use Resource Policies: Limit access by IP, VPC, or region. Lock Down Stages: Don’t let dev or test APIs live publicly. Clean Up: Remove unused APIs, keys, and stale endpoints regularly. Tag Everything: Helps in audits, cleanups, and figuring out what’s actually in use. --- 5 Key Security Best practices for Startups: Lock down your cloud: Cloud security for startups begins with cleaning up AWS. Apply least-privilege principles, restrict IAM roles, and disable unused services. Encrypt anything sensitive and check that public access isn’t enabled where it shouldn’t be. Enforce MFA and password policies: No excuses here, multi-factor authentication (MFA) should be required for all users. Enforce strong password policies and regularly rotate credentials. Train your team: People are the easiest way in. Teach your team to spot phishing, use password managers, and avoid oversharing sensitive info across tools. Patch early, patch often: Unpatched services and applications are open invites. Automate updates where you can and schedule regular check-ins for everything else. Monitor everything: get alerts on permission changes, new resources, and unusual access patterns. Better to catch it early than clean up after. Security for startups: Make it happen without slowing down Security for startups doesn’t have to mean buying bloated platforms or hiring consultants, and you don’t need a full-blown security team to get the security basics right. Start with automated tools For example The Sola App Gallery has plug-and-play solutions, including the AWS security app built specifically for startups. If you have more niche needs, Sola lets you build your own app from scratch, by simply writing a prompt to Sola AI and asking exactly the security question you care about: "is my S3 bucket public? ", "who has access to prod? ", etc. --- ---