Platform User Guide

The Zenity User Guide is the centralized Knowledge Base for securing applications built on Low-Code/No-Code development platforms and provides in-depth details on how these applications expose your organization to more risk.

Read this User Guide to learn more about Zenity features and workflows.
This guide explains each component of the Zenity platform, explaining when, how, and why to use each feature.

Zenity has two dashboards and provides a number of different views that end users can leverage to improve visibility, risk assessment, and governance. This guide is divided according to the interface screen viewable on the left-side menu.

Main Dashboard

The Zenity Main Dashboard offers valuable insights into data collected both from the Low-Code/No-Code platforms in production, and internally. The Main Dashboard is a great way to gain instant insights, and use it as a jumping off point when diving deeper for further discovery and analysis.

The Main Dashboard can be filtered by the following parameters using the filter settings at the top of the dashboard:

• Integration

• Policy

• Environment

Main Dashboard components

Top OWASP/MITRE

• Classification of all security violations mapped to the OWASP (for low-code/no-code) and MITRE frameworks, grouped by severity, red (high), orange (medium), or yellow (low) per category. Violations are clickable and take you to the Violations page, with the appropriate filter in place, allowing easy drill-down and detailed information access.

The Top OWASP/MITRE widget provides answers to questions, such as:

• What are the risk categories jeopardizing my organization that need attention?

• From an organization/department perspective, where do I need to focus first?

• What security best practices and training are needed in my organization and for whom?

• How are risks mapped or divided in my organization?

Using two different types of scores, Risk Mapping Score the critical risk areas you should focus on:

• Security Risk Score: Violation severity aggregation per resource

• Business Criticality Score: Using collected data, calculation of the potential impact a resource may have on your organization. For example, the type of Connector used (Finance, Sales, Customer Success) or the lifetime of the resource. A number of parameters taken into account in this score calculation. For more details, refer to the Business Criticality Score section of this document.

The Risk Mapping Score widget helps provide answers to questions, such as:

• What are the risky resources that if exploited, would cause my organization the most harm?

• How can I identify critical apps built by citizen developers?

• Which security risks should I address first?

• What areas of my organization are healthy, and what can be learn from them?

• How do I find the needle in the haystack, or the issues I should be concerned about first?

• How is risk mapped in each department, and environment?

Combining the Security Risk Score and the Business Criticality scores provides a clear understanding of where to start when handling potential risks. Clicking on any box in this widget will take you to the relevant resources, appropriately filtered on the Inventory screen.

-

Low-Code/No-Code Adoption

How can you see what's happening in your organization over time? The Low-Code/No-Code Adoption widget details the main resources being built in your tenant across platforms over time.

• View the growth and adoption of citizen and pro development using low-code/no-code platforms and broken up by category for deeper visibility

The Low-Code/No-Code Adoption widget helps provide answers to questions, such as:

• How fast is LCNC growing in your organization?

• How can I measure the growth of LCNC objects such as Applications and Automations?

• Can I forecast the LCNC adoption, in Month/Quarter/Year from now?

• Can I detect anomalies or spikes in usage and map them to actual events? For example, a new department starting or scaling up to use low-code/no-code.

• Is there a clear metric/KPI I can measure to reflect back to my leadership to showcase how LCNC is driving digital transformation in our organization?

• Which department uses LCNC the most? Which department isn't using any at all?

• Can I track what my users are building overtime?

Open Violations

The Open Violations widget provides a compact view of all open violations within your organization, grouped by their severity. Note that Exempt and Resolved violations are not counted or displayed here.

• Open violations are grouped by severity (High, Medium, Low).

• Customize the severity level of each rule under Policy → Violation Rules.

Passed & Failed Security Rules

The Passed and Failed Security Rules widget displays the number of violation rules that passed and/or failed in the latest scan. This provides data for the rules that did and did not trigger any violations. Note: only Active rules are counted.

Visibility Dashboard

The Zenity Visibility Dashboard offers valuable insights into the data collected both from the Low-Code/No-Code platforms being used by your organization and internally. The Visibility Dashboard provides insights on top of the Inventory view.

The Visibility Dashboard acts as an aggregator of all data collected from your Low-Code / No-Code application inventory, and is a key component of bringing visibility throughout the business.

The Visibility Dashboard has three main sections to provide an in-depth understanding of exactly how low-code/no-code is used in your organization.

• Total

Resource aggregator to help you understand the size of your tenant and how much it's growing.

• Builders Adoption & Growth

Focuses on the users who are actively building applications and automations and provides insights to help you and your organization identify their LCNC champions and adoption trends.

• Management & Clean Up

Focuses on your clean up, reassignment and cost saving opportunities.

The Visibility Dashboard serves as Zenity's landing page, and the view can be filtered by:

• Integration

• Policy

• Environment

Total

Primary resource aggregation based on the data from all platforms, sorted by resource category.

• Application - All application types across all platforms, such as, PowerPlatform Canvas and Model driven applications

• Automations - All automation types across all platforms, such as: Workato's recipes and PowerPlatform Flows.

• Connections - All data connections across all platforms, such as: Workato's connections and PowerPlatform connections.

• Environments - All logical resource containers across all platforms, such as: Workato's projects and PowerPlatform Environments.

Top Builders

• Surfaces the Low-Code/No-Code champions within your organization, displaying details of whomever is building the largest number of Applications and Automations.

Builders Adoption and Growth enables your organization to track and identify the users who are leading your digital transformation in LCNC and creating the most resources using low-code / no-code development platforms. These users are transforming your business, but also require the deepest level of security awareness and training.

Builders Adoption and Growth can help you answer critical questions such as:

• Who are my champions? Who needs the most security training? Who needs to be closer to security teams?

• Are our champions full-time employees? External vendors?

• Are our champions regular users? Service accounts?

• Can I identify if a champion with many applications and automation is still employed?

• Can I identify the roles of our champions?

• Can I easily understand what champions have built? How can I access and review it?

Builder Adoption

Surfaces the growth in Low-Code/No-Code developers, both citizen and professional, showing how many unique builders are building Automations and Applications in your organization over time.

Using the Builder Adoption widget, you can track and understand the magnitude of impact citizen developers and professional developers have within your organization, and see the trends of your created applications and automations. Builder Adoption can help answer critical questions, such as:

• Can I forecast LCNC adoption a Month/Quarter/Year from now? Can I prepare in advance?

• Can I detect anomalies or spikes in usage and map them to actual events? For example, how can I know if/when a new department starts to use low-code/no-code?

• Is there a clear metric/KPI I can use to measure to reflect back to my leadership and showcase how users in our organization are being transformed into citizen developers?

• Am I utilizing my licenses correctly?

• Which department uses LCNC the most? Which department doesn't use it at all?

• Can I track what users are focusing on? (Application/Automation)?

• Can I track and manage our builder usage across the entire business?

Orphan Resources

Over time, builders and creators of LCNC resources will leave the organization which results in orphaned, or unowned resources that can be blind spots for organizations. The Orphan Resources widget provides opportunities to clean up the system while saving money and make sure the system is compliant with company policy. Shows all the Applications, Automations, Connections and Environments that don't have an owner therefore candidates for reassignment or deletion.

Unused Resources

Over time, LCNC resources may either grow stale or no longer be needed due to changing business needs. It means that you have a real opportunity to clean up your platform while saving cost, this widget shows all of the Applications, Automations, Connections and Environments that are not in use and are candidates for deletion or further investigation.

Inventory

The Inventory reflects our belief and a well-accepted fact in security that you can't protect what you can't see . The inventory page displays everything built and configured on Low-Code/No-Code platforms, including Applications, Automations, and data connections.

Normally, when using Low-Code/No-Code platforms, Platform Administrators and security teams lack full visibility into what's happening within their organization. This lack of transparency and access is counterintuitive for enterprise security needs.

The Inventory that Zenity is able to gather is the result of continuous and comprehensive research and scanning into different LCNC platforms, understanding how they are built, consolidating all of their internal components into a single cohesive catalog, and providing it in a format where you can both view and take immediate action on anything displayed.

Zenity Inventory presents internal components as Resources categorized across different platforms, such as Applications, Automations, Connections, and more.

Zenity scans every corner of the various low-code / no-code platforms, mapping every resource and how they relate to one another. Understanding the inner ties between your Resources and revealing the relationships and potential risks they pose, while providing insights to how to mitigate them correctly is critical. Zenity Inventory provides the ability to see exactly which Connectors are used in a Flow, or quickly determine which of your users owns a specific application or automation, and more.

The Inventory helps to answer a range of questions, such as:

• Is my system being continuously monitored?

• What environments do I govern?

• What flows/applications are not in use? Which external users have access to my platform?

• Which flows are moving data outside of my organization?

Inventory Best Practice:

Use Zenity's Inventory features in tandem with the actual violation under investigation. This method allows you to go back and forth between the original Resource causing the violation, and any related resources that can provide context for what the Resource does and what it affects.

You can search, filter, and sort from the top of the Inventory page to find any resource.

Click on a Resource to access the four detail tabs (Overview, Relations, Violations, Hygiene) on the side panel.

• Overview: Provides the resource profile, including summary details and a timeline.

• Relations: A list of all relations for the resource, who created it, who's using it, what connections it has, and more.

• Clicking on "Explore" on any of the resources presents the main page showing all "Related Resources." This helps guide you through the relations map and understand how the resources are connected.

• You can also use the top filters to view only relevant relations.

• Violations: Any violations triggered for this resource (click through to view the actual violation details).

• Hygiene: Any Hygiene issues triggered for this resource (click through to view the actual Hygiene issue details).

Zenity provides users with an ever-growing set of 1-Click fixes in the form of ad-hoc actions. Using the respective 3rd party API and other methods, Zenity allows users to perform mitigation and management actions. Examples include:

• Stopping a potentially malicious automation.

• Reassigning ownership for orphan applications so all applications are owned and governed.

• Deleting personal connections that can lead to data exfiltration.

• Sending emails directly to the builders notifying them about issues found on their resources and providing them guidance on how to fix them, and many more.

Violations

Zenity's Violations screen provides dedicated risk assessments to your Low-Code/No-Code ecosystem. assessments in the.

The purpose of each violation is to provide a snapshot of the following:

1. What happened? Includes what Zenity detected and how we detected it.

2. Why is this a risk? Explicit description of how this violation exposes the organization to an attack.

3. How to triage? A list of steps to help you assess the magnitude of the risk and its potential impact.

4. How to fix it? Concrete actions you can and should take that help mitigate the risk. Most can be taken directly from Zenity.

The Violation page is yours to control. Search, filter, and sort, to focus on exactly what you need and want to investigate further

In addition to the Remediation actions provided, Zenity also offers options for administrators to help simplify the operations load.

• Exempt: Ignores a violation and ensures the same violation won't be displayed again for the same rule and resource combination.

If you've discovered a false-positive violation, you can easily remove it by clicking on the "Exempt" button under "Actions." This will ensure the same violation will not repeat itself for this specific resource.

Violations are categorized by the [OWASP Top 10 Low-Code/No-Code Security Risks, which Zenity is a founding member for,] for ease of use and context.

Investigating the violation in tandem with the Inventory is the recommended best practice using Zenity. It allows you to get more in-depth information about the resource triggering the violation and its related resources.

Zenity provides users with an ever-growing set of 1-fix clicks in the form of ad-hoc actions. Using the respective 3rd party API and other methods, Zenity allows users to perform mitigation and management actions. Examples include:

• Stopping a potentially malicious Automation.

• Reassigning ownership for orphan Applications so all applications are owned and governed.

• Deleting personal connections that can lead to data exfiltration.

• Sending emails directly to the builders notifying them about issues found on their resources and providing them guidance on how to fix them, and many more.

Ad-Hoc Actions (Click2fix)

Zenity has a large set of remediation actions, directly impacting the Low-Code/No-Code resources.

PowerPlatform

Canvas App

• Quarantine (blocks access to all users except for the main owner)
• Unquarantine
• Set Access (Add co-Owner / remove all levels of access)
• Delete
• Send Email

Flow

• Stop
• Start
• Set Access (Add co-owner / remove all levels of access)
• Delete
• Secure Flow Steps

Secure Flow Steps additional information: As per the action's intent it will be available when sensitive data is found, Zenity users can correlate this to the below rules:

• ZN_P00121 - PHI sensitive data handled by a flow (Preview)
  
• ZN_P00117 - PII sensitive data handled by a flow (Preview)
  
• ZN_P00099 - PCI sensitive data handled by a flow
  

The action currently supports solution aware flows (meaning flows created within a solution).

The action masks the sensitive data in the logs by enabling the 'Secure Input/Output' configuration in PowerAutomate only for the violating steps in the flow.

Customers can use our API today to handle sensitive data exposure by enumerating through all relevant violations and invoking the new action. This will ensure that the sensitive data is protected and hidden.

Connection

• Stop all flows
• Delete
• Send Email
• Add Owner - (Only for shareable connections)

Custom Connector

• Add Owner
• Send Email

Environments

• Add Owner
• Remove Owner
• Delete
• Send Email

Hygiene

Maintaining hygiene is a critical aspect of proper governance policies, and Zenity's Hygiene screen displays issues related to the management of your Low-Code/No-Code platforms. Zenity Hygiene offers multiple views and filters to help you clean up your tenant. For example, highlighting unused resources to remove and free up space and licenses, while reducing costs or displaying orphan resources that need to be reassigned to a relevant owner, and more.

Beyond maintenance clean-ups, Zenity alerts when users leave your organization and highlights the stranded resources left behind with no management. In quick departures, shared resources can still be active and used by other users, without an administrator.

Zenity also provides best practices on how to manage and configure your different low-code platforms.

Zenity provides a growing set of 1- click fix in the form of ad-hoc actions. Using the respective 3rd party API and other methods, you can perform mitigation and management actions such as the following examples:

• Stopping a potentially malicious Automation.

• Reassigning ownership for orphan Applications so all applications are owned and governed.

• Alerting about deletion of personal connections that may lead to data exfiltration.

• Directly emailing builders notifying them about issues found on their resources, and providing guidance on how to fix issues, and more.

Policies

A key part of the Zenity governance functionality, Policies enable administrators and security teams to apply critical guardrails that enable continuing citizen development without risk or impact to their business security procedures.

There are two types of policies.

• Default Policy: Integrations configured in Zenity have a "Default" Policy, governing all the environments and resources within them by default. This means that without doing anything, users always have Zenity's best practices guardrails in place.

• Custom Policy: Custom Policies allow users to enforce different security controls based on the environment. It means Zenity can behave differently, in terms of detection and response, for resources found in a production environment versus a sandbox environment. Custom policies provide granular guardrails as there isn't a one size fits all approach to security, especially for enterprises.

Click on the Default Policy (or any custom policy) to see the entire set of violation rules, and configure them.

Rules are grouped by the OWASP framework by default, and for each category a link to the relevant OWASP Low-Code/No-Code community is provided. A rule view based on the MITRE attack framework is also provided.

Each rule can be Disabled/Enabled, and the rule Severity level can also be changed as required for your platform.

Every time a rule is updated, users will receive an indication in the UI letting them know about the change in the default configuration. Users can always reset the changes back to default.

Once you click on the Policy, you also gain access to the Configuration of that policy.

The policy configuration is where users can configure the rules.

Inside the Policy settings, there are 4 different sub-menus.

• General

• Trusted Domain

• Connectors

• Environment

General

The General tab exposes some of the basic rule configurations available. For example, the allowed number of builders for a flow (to trigger in case there are too many users with privileged access over a resource) or "Allow connections to Production" (alerting in case we see a connection between a non-production and a production environment or vice versa). Many more will be added in the future.

Trusted Domains

The Trusted Domains tab lists your organization's domains. Once configured, Zenity will flag any usage or configuration for a data connection or data leak communicating with the untrusted domain. The list can consist of any domain your company owns directly, through a subsidiary, and also approved 3rd party domains. For example, a vendor that provides service to the company and needs access to your Low-Code/No-Code platform.

Connectors

The Connectors tab controls your Data Flow rules.

Data Flow rules flag potentially risky data movement within your organization's Low-Code/No-Code environment. Using categories such as Social Media, Cloud Business, Data High Risk and more, the Connectors tab can help to view and edit the connectors within the relevant categories to get your desired controls.

For example, if your organization prohibits the use of Google Drive, you would want to add the Google Drive Connector to the High-Risk category. As Zenity scans your environment, all Automations in the tenant are reviewed, so that if any of them use Google Drive with a combination of other connectors from different categories,- the corresponding alert is issued.

By default, Zenity defines connectors in different categories. Make sure to review your connector categories and adjust as needed based on your organizational policies.

You can Create, Delete, or Edit custom policies and assign different environments to them to provide different policy detection and enforcement strategies for different environments.

Does anyone currently know how your data typically moves?

A real world example might be an automation moving data from a Social-Media platform to a Business Cloud Application. In this example, there is an automation where every company LinkedIn Post updates a file in the organizational SharePoint, or the reverse. Using Zenity Data Flow, the exact Connectors in use are displayed. show the exact Connectors used.

How do I perform a Data Flow Risk Assessment?

From the Policy page under Violation rules, click on any of the data flow rules (starting with "A combination of..." to access the relevant violation and view the relevant automation. From the Inventory page, you'll see additional information about the automation, view the automation timeline, related resources, violations, and any related hygiene issues.

Connectors can be updated within every category by accessing the Policies page under the Connectors section within Zenity.

Environments

Environments are logical containers for resources, originating from the source platform. For example, an Environment can contain Applications and Automations.

Zenity queries the LCNC platform and brings in those logical containers called "environments" so a customer can view them and associate them with different policies, thus achieving different security enforcement to best fit the organization's needs.

Consider the following scenario:

An organization has 3 Environments: Production, Test, and Development

Each of these environments have various resources such as: Application, Automations, and Data Connections

From a security enforcement perspective, each of these environments and their resources can be entirely different.

Production environments typically have stricter enforcement, such as elevated levels of rule security and less tolerance for bad practices and mistakes.

However, in Development, environments typically favor a more research oriented approach, allowing for more trial and error, while continuing to monitor and supervise.

To implement this within Zenity, there would be two different policies, one for Production and the other for Development. Configure each policy based on the specific needs and approach of your company, then assign the relevant resources to each environment.

Different platforms have different terminology for what we commonly refer to as environments.For example, Power Platform uses "Environments", Workato uses "Projects", and Zapier uses "Accounts". Zenity aligns all to a common term.

A user may configure a "Production" policy to achieve stricter rules as opposed to a "Sandbox" policy, applying more severe playbooks for production.

Users can create a production policy and associate critical environments with it. Users can also configure various rules to be classified as high severity and create correspondingly more strict playbooks to mitigate violations. For example, if a risky connection is found, the playbook can immediately delete the connection and then contact the builder of that connection.

In less strict environments, as an example, the playbook could notify the builder first without automatically deleting the connection.

Endpoint Filtering

Low-Code/No-Code Applications and Automation are highly customizable and can have dozens of data interfaces, such as HTTP or SQL etc... How can security professionals ensure an Automation doesn't communicate with a malicious endpoint, for example a C&C server exposing the company to malware?

How can we help place guardrails and allow users to freely use the extensibility power that Low-Code/No-Code offers without losing sight of what's been used and how?

Zenity now launches the 1st version of our Endpoint filtering which will allow Platform admins and Security Professional to set the boundaries by configuring an HTTP/HTTPs Allowed list.

Any activity outside of the allowed list will result in a violation, search for ZN_P00123 - "[Flow is communicating with disallowed endpoints (Preview)to view violating flows.

In order to add a new endpoint to the list click on the "Add Endpoint" button on the right-top side of the table.

Users can add a full URL or only a domain.

Endpoint filtering currently covers HTTP/HTTPS URLS.

When adding a domain, Zenity will match both HTTP & HTTPS requests. If the protocol is explicitly stated, Zenity will match the domain along with the specific protocol.

Endpoint Filtering supports the use of a wildcard

Customers can only use (*) at the end of an expression, in the following manner.

Option A -

.sharepoint.com/*

This means that all URLS after the '/' are allowed (including any consecutive '/' in the path)

Option B - .sharepoint.com/Lists/Customers*

This means that anything matching '/Customers is allowed for example '/Customers_customerA, '/Customers_CustomerB.

Usage of wildcards in any other way would result in a validation error.

Integrations

Integrations are where the Zenity administrator establishes the connection between Zenity and various Low-Code/No-Code platforms.

Based on the platform and the authentication type, someone in your organization will need to provide an API key/token or a username and password to authenticate correctly.

An Integration status will change to Active as soon as the integration is successful. Zenity will then begin scanning the integrated Low-Code/No-Code Platform.

Note: Only your organization's Zenity Administrator can create, edit, Retry or delete an integration.

In the event of an integration failure, the integration status will change, and your Zenity Admin will need to retrigger the scan by clicking on the 'Retry' button.

Playbooks

Playbooks are Zenity's automated response to Low-Code/No-Code environmental violations and hygiene issues. When combined with Zenity Policies, Playbooks help define and implement governance and security within your Low-Code/No-Code environments.

The purposes of Zenity playbooks are to:

• Fix/remediate/mitigate violations and hygiene issues.

• Remove/Reduce manual tasks.

• Speed reaction time to violations and hygiene issues.

• Guarantee issues cannot be dropped or missed.

• Streamline the organizational processes.

• Enable handling of a high volume of issues using a smaller number of resources.

In Zenity, playbooks are created to address the different types of violations found or address changes your inventory.

Playbooks are made from Triggers and Actions.

Step 1: Configure the basic information of the playbook, such as: Name, Description, Platform, Integration, and Policy.

Step 2: Configure the structure of the playbook by setting up the Trigger and relevant Actions.

Playbook Structure

Zenity playbooks follow a standard structure of Trigger and resulting Actions. Triggers define the event that will initiate the playbook (user configurable). Actions are all of the possible results or responses to the trigger

Trigger: Define the event that initiates the playbook. This can be configured on a user-by-user basis.

A good example of a trigger is detection of a new violation. Note: Zenity includes a wide set of configurations to ensure Zenity only addresses specific cases, or casts as wide a net as you require.

Examples:

1. Violation of a certain type (specific rule or multiple rules).

2. Severity

3. Resource status, Resource Security Risk, Resource Business Criticality, and more.

There are 2 trigger types in Zenity.

1. A new violation was found
2. A new resource was found

Meaning, that customers can initiate automation processes based on either of the above.

Actions: A response (following the trigger or other actions) to communicate directly with the Low-Code/No-Code platform. For example, Delete an Application, Stop an Automation or Communicate Internally (such as sending a notification email). Multiple actions can be configured on the same playbook.

Actions are based on the resources and not all resources have the same possible actions on the source platform. Each Action is strictly tied to the trigger and its specific configuration. The wider the trigger configuration the fewer possible actions will be available, while more narrow trigger configurations will have more actions available.

For example, a playbook with a trigger that detects risky applications will have the option to Delete the app. In the case where a user edits the trigger for the same playbook to also detect risky automations, the Delete action will no longer be available, as those are different actions on the source platform. In such a scenario, you can only Send an email which is the basic action available for any trigger.

There are unique actions only relevant for playbooks.

Wait

The wait action will put the playbook in a freeze state, which is helpful in case you want to provide enough time to receive an answer. A simple example, can be a playbook that triggers for an issue with a connection, here is how the playbook would look like:

Step 1 - 'contact maker' via email (notifying him about the violation and pending deletion) Step 2 - wait for 7 days Step 3 - 'contact maker' via email (notifying him about the violation and pending deletion) Step 4 - wait for 7 days Step 5 - Delete connection Step 6 - 'Contact Maker' via email (notifying him about the deletion)

In this case, we provided enough time for the user to reply and fix the issue before taking measures to resolve the issue.

At the end of the 'Wait' period the playbook will make sure that the violation is still relevant before continuing to the next step. In case the violation was resolved or exempted the playbook will stop running.

Export to Webhook

The export to webhook is a great method of integrating with 3rd party platforms. In case, a customer wants to stream the Zenity events to another location and handle aggregation in a centralized repo, such as a SIEM, or a SOAR solution.

Zenity allows to easily set up a webhook and to stream all violations or a subset of them to any platform in the world that supports an incoming webhook (HTTP), which is true for the majority of platforms today.

Settings

Zenity Administrators can easily manage Access within Zenity, using the Settings page.

The Settings displays users and their respective roles (permissions).

Only Administrators can view this page and are able to invite new users, delete Users and update roles.

Administrator - a power user with the highest level of permissions including all actions and integration setup.

Operator - a user that can view all and perform actions on violations and inventory resources (except for specific ones), Operator are not able to create/delete/update integrations.

Analyst – a user with read access to all data required for risk analysis, including sensitive information such as Copilot transcripts (prompts) and tool invocation parameters, fetch raw inventory resource definition. Analysts can investigate and triage violations/runtime findings, but cannot perform any modification actions.

Viewer - a read-only user that can view anything in Zenity (except for the integration details), cannot perform any action.

Users can view the role when clicking on the profile icon on the left-upper side of Zenity.

In addition, administrators can view the API key of their respective Zenity instance and easily rotate the key if needed.

API Reference

Zenity is an API-first product, meaning everything possible in the UI is also available using the Zenity API. The Zenity API is integrated in Zenity, and Zenity users can view and integrate within Zenity for custom work.

Miscellaneous

Business Criticality Score

Zenity evaluates each resource's Business Criticality (BC) score in the following manner.

Each resource is scanned and reviewed using the below attributes, each of them has a score that aggregates to the overall BC score.

Score Attributes:

\ Connector Category

Zenity classifies each Connector to a category (Finance, HR, Support, etc.) with a Low/Med/High BC score. For example, an Oracle NetSuite connector is within the Finance category, and therefore has a High BC Score.

How is the Score Calculation done?

• When a resource has more than two attributes with a High score, the resource is given a High BC score.

• When a resource has more than two attributes with a Medium score, the resource is given a Medium BC score.

• In all other scenarios, resources receive a Low BC score.

This feature is currently going through rapid adaptation and expansion as Zenity gains additional critical Information for score enrichment.

Rules

Rules are a fundamental part of how the Zenity security engine operates.

Zenity continuously scans your platform for risks using a wide range of security rules.

Zenity currently supports 2 types of rules:

• Violation

Violation rules are comprised of all of the risk-oriented rules. (Violation rules are the majority of Zenity rule base)

• Hygiene Hygiene rules are Clean up and maintenance rules with minimal risk orientation, but can greatly help with platform clean-up and cost reduction.

Violation and Hygiene rules are visible from the Policies screen.

Rules Tags

Every rule has additional information that helps and provides more data about the rules. These are called Rules Tags.

The Rule Tags are easy to understand labels on the Rule itself, shedding more light about the rule.

For example, the existing phase provides clarity on the rule's state.

• Preview

• GA

• Deprecated

Preview Rules

New rules are introduced frequently at Zenity, and while some rules are focused around research, others are still in development and refinement. Rules that are still evolving are given a Preview Rule Tag.

Preview rules are rules the Zenity team is still optimizing, and may have a higher false-positive ratio. However, even though these rules are in active development, you can still view Preview rules and their corresponding results.

We aim to share our progress, while simultaneously recommending not to take immediate action on them as they are subject to change/deletion/merge with other rules etc.

Once rule optimization is completed for a Preview rule, the status change is publicly announced , and the rule will either become GA, or be Deprecated.

• In addition, Zenity users can filter using the new 'Rule Tag' filter to find only relevant violations.

• Playbooks also run on GA rules by default.

The available Tags are:

Lifecycle
- Preview
- GA
- Deprecated

Risk
- Exploitable - lets our customer know that certain rules are identifying scenarios where a path to exploit exists.

GA Rules

GA Rules are Certified Rules with both high confidence and a low False Positive ratio.

Rules usually become standard after a validation period in a Preview status.

Deprecated Rules

To make sure our rules stay up to date, remain relevant, and provide value, we constantly measure the rules and their platform context to ensure relevance. Due to the fast-evolving nature of Low-Code/No-Code, our rules also evolve on a regular basis, and in cases where we determine existing rules have limited or no value, we deprecate them.

Every rule deprecation process is communicated to all customers weeks before they actually get deprecated. This allows you to prepare well in advance and assess the potential impact. After the depreciation notification duration, rules and their violations are removed entirely from Zenity.

CVSS Violation Mapping

Zenity determines each violation rule severity using the CVSS 3.1 (Common Vulnerability Scoring System) framework.
As such each rule has a CVSS score that maps to one of the severities.

Violation Severity	CVSS Score Range
Low	0.1 - 3.9
Medium	4.0 - 6.9
High	7.0 - 10

Zenity Support

Contact Zenity Customer Support Need more help using Zenity, or with an integration? No problem, our Customer Support team is here to help.
Reach out to us at via the in-product support ticket (located on the upper-right side of every screen)
or via our email support@zenity.io for assistance.

Please make sure to add as many relevant details as possible in the ticket, including images to help expedite the cycle time.