Flowable security hardening guide

Why Flowable security hardening starts with the exposed surfaces

Security hardening for a Flowable deployment means securing the surfaces the engine exposes or depends on: the REST API, script tasks and expressions, database credentials and encryption, the Spring and Jackson dependency chain, audit history, and the permissions granted to service tasks. If your team is about to move a Flowable engine into a production network, these are the areas your sign-off has to cover. Each one is a place where a configuration choice or a missing review can turn a process engine into an entry point. The work is harder than it looks because Flowable is not a product with a管理 console that arrives hardened. Flowable is a set of embeddable Java libraries for BPMN, CMMN and DMN execution, and it can run inside a Spring application, a servlet container, a Java SE process, or behind the Flowable REST application. That means the security boundary is the application that hosts the engine: its network exposure, its authentication filters, its datasource configuration, its deployment pipeline and its logging. Flowable provides the engine behavior, but your team owns the perimeter around it. The engines are licensed under Apache 2.0, which is a permissive license that carries no vendor-enforced security defaults your team can rely on without review. Nothing in the open source distribution decides for you whether the REST API is reachable from the internet, whether script tasks may evaluate arbitrary expressions, or whether service tasks run under an account with broad database rights. Those decisions are yours, and they should be written down before the first deployment. A practical first step is to inventory every exposed surface in your planned architecture and assign an owner and a review decision to each. Ask who can deploy process definitions, which identities can start or complete tasks through the API, where database credentials are stored, and which Spring and Jackson versions are on the classpath. Confirm these details against the Flowable documentation for the exact version you plan to run, since the supported database types, Spring Boot baseline and Jackson default differ between major releases.

The Flowable components and settings that carry risk

A Flowable hardening review inspects a small set of surfaces that together decide who can reach the engines, what code runs inside a process, and what data the platform keeps. Each card below names one surface, what it exposes and where its settings live, so reviewers can walk the deployment from the network edge down to the database.

Flowable REST application or REST starter

The REST layer is the most exposed surface when Flowable runs over HTTP, either as the Flowable REST application or through the REST starter embedded in a Spring Boot service. Confirm which of the two you run, which endpoints are reachable from which networks, and whether authentication is enforced on every route, including the ones added for custom resources. Check the Spring Security configuration in your own code, because the engine does not decide who may start or complete a process on its own.

Java and REST APIs of the BPMN, CMMN, DMN and event registry engines

Each engine exposes a Java API for code inside your application and, where enabled, a REST API for callers outside it. Review which engines are deployed in each service, since a DMN or CMMN engine you do not use still widens the attack surface if its routes are exposed. Confirm that only the services that need an engine can call it, and that calls from other services pass through an authorization check you own.

Script tasks and expressions in process models

Script tasks and expressions run code defined inside process models, which means a person who can deploy or edit a model may be able to execute code on your server. Decide which scripting languages are permitted, whether expressions may call arbitrary Java beans, and who approves model changes before deployment. Inspect every deployed model for inline scripts and for expressions that reach into services with broad database or file access.

Database connection and supported database types

Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and the datasource settings govern the credentials the engine holds. Check that production uses a dedicated account with the privileges the schema needs and nothing more, that credentials come from a secrets store rather than configuration files, and that connections are encrypted in transit. Confirm the database type and version against the Flowable configuration docs for your release, since a MySQL version below 5.6.4 lacks millisecond precision.

Actuator endpoint at /actuator/flowable

The Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes. Because it reveals operational detail about process instances, it must sit behind the same authentication as the rest of the management plane, or be bound to an internal management port. Check the actuator exposure settings in your application configuration and confirm the endpoint does not appear on a public load balancer route.

Identity service and its user and group sources

The identity service decides which users and groups can act on tasks, and Flowable documents replacing IdmIdentityServiceImpl or implementing IdmIdentityService, with an LDAP implementation as a reference. Review which identity source feeds the engine, how group membership is refreshed, and whether a removed or disabled user loses task access promptly. Test that candidate groups on tasks match the authorization model you intend, because a wrong mapping grants access silently.

Async executor and its database lock records

The async executor runs timers and asynchronous jobs from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database. Review who can read or alter those lock rows, since tampering can stall jobs or let duplicate work run, and confirm the configured lock duration suits your longest job. Check the executor thread pool limits so an attacker who triggers many asynchronous jobs cannot exhaust server resources.

History data and audit records

History tables keep process variables, task assignments and timestamps that often contain personal or regulated data. Decide which history levels are enabled, how long records are retained, and who can query them through the API or directly in the database. Confirm that access to history is logged and that retention and purge jobs run as planned, since history is both an audit source and a data protection exposure.

Which hardening choices fit your deployment model

This table compares the main Flowable hardening decisions, from how the engine is deployed to how much history you keep and where authentication is enforced. Read each row against your own topology and audit obligations, because the safer option usually carries an operational cost that your team must own.

Decision	When it fits	Operational cost
Separate REST application or embedded engines	A separate REST service fits when several systems call Flowable over HTTP and you want one hardened process to patch. Embedding the engines in your own Spring or servlet application fits when only your code calls the engine and you want no HTTP surface at all.	The REST service adds a network surface, a second deployment, and authentication to configure. Embedding removes that surface but ties engine upgrades to your application release cycle.
Allow script tasks and expressions	Scripts fit teams that need quick process changes by business analysts and can review each script under change control.	Scripts widen what a modeler can execute on your servers, so each script needs review, versioning and a restricted runtime. Reviewed Java delegates cost more development time up front but keep execution logic in code your team already tests.
Restrict or expose the actuator endpoint	Restricting the /actuator/flowable endpoint fits production systems where only the platform team reads metrics from inside the network.	A restricted endpoint needs firewall rules or access controls, and monitoring tools need a path to reach it. Exposing it to monitoring simplifies dashboards but reveals process and instance details that need protection.
History level kept for audit	A fuller history level fits processes where auditors must reconstruct who did what and when, including variable changes.	Higher history levels increase database growth, index maintenance, and backup size. Confirm retention and purge jobs with your auditors before choosing the level, and test query performance on realistic volumes.
Network-only access	Network-only access fits internal engines reached only by a small set of trusted services on a segmented network.	Network controls alone give no per-user or per-client authorization, so audit trails will not show which caller acted. Plan compensating controls and confirm the model with your security team.
Gateway-enforced authentication	Gateway enforcement fits environments with an existing API gateway or service mesh that already issues and checks tokens for internal APIs.	The gateway becomes a required control point that must be configured, monitored and patched. Engine-side checks may still be needed for defense in depth, and the design must be confirmed against your identity setup.

How to build the hardened configuration, step by step

This sequence takes a Flowable deployment from an unknown exposure to a documented, tested configuration. Each step names the decision it produces and the check that confirms it before the next step begins.

Inventory exposed endpoints and models
Your platform or application owner lists every REST path and actuator endpoint the running deployment exposes, including the monitoring endpoint at /actuator/flowable. Then list every BPMN, CMMN and DMN model that contains script tasks, expressions or Java delegates, with a named owner for each. Confirm the REST paths against the REST section of the Flowable docs for your version, and confirm the actuator exposure in the Spring Boot chapter. The output is one inventory with a row per endpoint and per model. The step is done when someone outside the project can reproduce the endpoint list from the running system and the model list from the repository.
Restrict network paths to the API and actuator
Your network or platform team limits access to the REST base path and the actuator endpoints to the callers and monitoring hosts in your inventory. Keep the management endpoints on a separate port or an internal network where your Spring Boot version supports it. Confirm the management port and endpoint exposure settings in the Spring Boot chapter of the Flowable docs. Authentication for approved callers is covered by the identity integration work, so this step only controls which paths can be reached. The check: a request from an unapproved network segment to the REST path and actuator paths is blocked at the firewall or load balancer, and a request from an approved host still reaches the service.
Decide the script policy and enforce it in review
Your architecture and security leads decide which script languages, if any, are allowed in script tasks and expressions, and whether business analysts may edit scripts at all. Write the decision as a one-page policy that names the approved patterns, such as calling a named Java delegate instead of embedding code. Confirm which script and expression features are enabled for your engine version in the Configuration and Advanced chapters of the Flowable docs. Then add a gate to model review so any BPMN, CMMN or DMN change that adds script content needs approval from a named engineer. The check: a test model containing an unapproved script fails the review gate.
Move database credentials into the secret store
Your platform engineers find every place that holds the database user name and password, including datasource property files, environment files, container images and CI variables. They move the values into the team's secret store and inject them into the application at startup. Confirm the datasource property names in the Configuration chapter for your engine and starter, because the names differ between setups. Remove plaintext copies from the repository history where your team's policy requires it. The check: a scan of the repository, build artifacts and container images finds no plaintext database password, and the application starts with the value supplied by the secret store.
Set history retention and confirm recorded events
Your compliance lead and the Flowable owner agree which process events must be recorded for audit, how long history is kept, and who may read it. Then they confirm the history level and cleanup settings in the Configuration chapter and the history-related sections of the Advanced chapter. Run a test process from start to completion, and query the history tables to see which events are written. The check: the events in the test run match the audit list agreed with compliance, and the cleanup behavior matches the retention period in the policy. Ask the auditor to confirm the retention period they expect before setting it.
Assign least-privilege database and service accounts
Your database administrator creates a runtime database account with only the rights the engine needs to run processes and jobs, separate from the owner account used for schema creation and upgrades. For service tasks and Java delegates, the integration owner records which identity each delegate runs under and limits that identity to the systems it calls. Confirm the schema creation and upgrade behavior in the Configuration chapter before removing any rights, since the engine creates and updates tables. The check: normal process flows succeed under the runtime account, and a schema upgrade succeeds only under the owner account in a test environment.
Pin and scan dependencies
Your build owner pins the Flowable, Spring and Jackson versions in the build file and records the exact versions in a bill of materials. Run a software composition scan on every build and assign each finding to an owner. Note that Flowable 8.0.0 moved to Spring Framework 7 and Spring Boot 4, with Jackson 3 as the default JSON library and a Jackson 2 compatibility layer, so the pinned versions must match the version you tested. The check: the build fails when a dependency is unpinned or flagged above the threshold your team sets, and the scan report is stored with each release.
Run the verification pass
Your QA and security team runs the checks from steps one to seven again in a staging environment that matches production. The pass covers endpoint reachability from outside approved paths, script policy rejection, a secret scan, the audit events from a test run, account permission tests, and the dependency scan. The owner of each step records the result against that step. The check: every step has a recorded pass signed by its owner, and any failure reopens that step before go-live. Keep the results with the configuration so the next upgrade can repeat the same pass.

Keeping Spring and Jackson patched without breaking process models

Keeping Spring and Jackson current is a hardening control for Flowable because both libraries sit on the paths that matter most. Spring handles the HTTP layer when the Flowable REST application or your own endpoints are exposed, and Jackson parses request bodies and serializes process variables, including those that carry customer or case data. A known weakness in either library can therefore reach the engine through ordinary API traffic. The difficulty is that a currency update in this stack is rarely a routine patch. Moving to a newer major line can change the Spring Boot baseline, the JSON mapping behavior and the test framework at the same time.

The 8.0.0 release shows how large that change can be. Flowable 8.0.0, released on February 27, 2026, moves to Spring Framework 7 and Spring Boot 4 and does not support Spring Boot 3. Jackson 3 becomes the default JSON library, with a Jackson 2 compatibility layer that lets existing code keep working for a period. Custom serializers, Jackson mixins and any code that reads or writes process variables as JSON need review on both sides of that layer. JUnit 3 and 4 support has also been removed, so older test suites will not run unchanged. Earlier, the 7.0.0 line moved to Java 17, Spring Boot 3 and Jakarta EE, so a team still on an older release may face two baseline changes at once.

Teams usually choose between three paths. The first is to stay on a supported Flowable line and take patch releases within it, which keeps the change small but depends on the vendor continuing to ship fixes for that line. The second is to scan transitive dependencies on every build, because the versions of Spring and Jackson that reach production often come from the Flowable dependency tree rather than from your own declarations. Overrides should be added only when tests show the process models still behave correctly. The third is to plan the jump to 8.0 as a scheduled project with its own test window. The full upgrade sequence, including schema changes and regression testing, is covered on the Flowable upgrades and support page, so this section focuses on how to decide between the paths.

Before choosing a path, confirm the current CVE status for the exact Flowable, Spring and Jackson versions you run. No vulnerability data is included here, so this page makes no claim about which versions are affected. Ask Flowable and the Spring project for their current support and advisory channels, and run your software composition scanner against the built artifact of each service, not only the root project. Record the result as an inventory: the Flowable, Spring and Jackson versions per service, the scanner findings, the owner of each exception and a review date. That inventory gives your security team evidence for a compliance assessment and gives the engineering team a clear starting point for the upgrade decision.

What drives the effort and cost of Flowable hardening

This table lists the inventory items that change how much review, testing and evidence a Flowable hardening project needs, with the effect of each and how to keep it down. Read each row against your own environment, because the counts you collect before scoping are what a fixed-scope quote is built from. The main takeaway is that a complete model and endpoint list, produced first, makes the written scope and the quote far more reliable.

Driver	Effect on effort	How to keep it down
Process and case models with script tasks or expressions	Each script task and expression that evaluates dynamic code must be reviewed for injection, unsafe classes and data exposure, so effort grows with the count of models that use them.	Replace scripts with delegates or declarative expressions where possible, and list every model that contains one before scoping.
REST endpoints and API clients	Every exposed endpoint needs authentication, authorization and input checks, and each client role needs its own access test.	Expose only the REST application endpoints the business needs and document which clients call each one.
Integrations and service tasks calling external systems	Each outbound call needs credential handling, timeouts, error paths and least-privilege accounts, which multiplies testing per system.	Group integrations by target system and reuse one hardened connector pattern across service tasks.
Environments, including any air-gapped network	Development, test, production and isolated networks each need configuration, secrets and evidence, and air-gapped sites add offline dependency and update handling.	Keep configuration in one parameterized source and confirm early which environments need separate evidence.
Identity and secrets systems to integrate	Connecting the identity provider, directory and secrets store adds configuration, role mapping and rotation tests for each system.	Confirm which identity source is authoritative and which secrets store holds database credentials before scoping.
Compliance framework whose evidence must be produced	The framework sets which controls, logs and records must be shown to an assessor, and broader scope adds evidence work on top of the technical hardening.	Name the framework and the control set early, and agree with your assessor which evidence format they expect.
Amount of custom Java delegate code	Each custom delegate needs code review, dependency checks and tests, so effort tracks the number and size of delegate classes.	Count delegate classes and their external calls, and review shared utility code once rather than per process.

How hardening differs by deployment model

When Flowable runs as a JAR inside your own Java SE, servlet container, Spring or Java EE application, the engine shares a process with your business code. Most hardening work sits in the application: which code can reach the engine, what delegates and expressions do at runtime, and how the datasource is configured.

Java API surface: any code that holds an engine bean can start, complete or query process instances, so limit which services receive those beans.
Expressions and script tasks: expressions and scripts run inside the application's JVM with its privileges, so review which script languages are enabled and who can change deployed models.
Datasource credentials: connection settings usually live in application configuration, so move them to your secrets store and confirm the database account holds only the privileges the schema needs.
Actuator endpoint: the Spring Boot starters expose a monitoring endpoint at /actuator/flowable, so confirm it is bound to an internal interface and protected by your Spring Security configuration.

Confirm with your application team which code paths reach the engine and whether models are deployed only through reviewed releases or also at runtime.

Hardening controls for access, secrets and audit history

Flowable's engines, REST API and actuator endpoint each open a path into a running process platform. The controls below cover how that access is authenticated, how scripts and credentials are governed, how service tasks reach other systems, and what history the engine keeps. Most are configuration the team owns, so each card names what to check and who decides.

REST API and actuator exposure

The Flowable REST application and the actuator endpoint at /actuator/flowable are separate HTTP surfaces, and each needs an explicit exposure decision. Enforce authentication at the API gateway or network layer, and confirm which paths are reachable from outside the cluster. Restrict the actuator to monitoring networks or a separate management port, and check that Spring Security rules cover it. Test both surfaces with unauthenticated requests after every release, because these settings are configuration the team owns.

Script task and expression policy

Script tasks and expressions run logic inside the engine, so each script needs a named owner and a review gate before deployment. Where a Java delegate can replace a script, prefer the delegate, since it passes through standard code review and automated tests. Decide whether script languages are permitted in production at all, and confirm how your engine version evaluates expressions. Treat changes to process XML as code changes, and block deployment of models from ungoverned sources. The team that owns the process models makes these decisions.

Database credentials and rotation

The Flowable schema connects through a database account, and that credential should live in a secret manager. Keep it out of configuration files and source control. Use separate accounts for development, test and production, and grant each account only the privileges the engine needs on its own schema. Set a rotation schedule and confirm that the application picks up a rotated credential without a manual restart. Ask your secret manager and database platform which rotation methods they support.

Encryption at rest and in transit

Encryption at rest is handled by the database platform, so confirm which options your chosen database offers, such as native tablespace or column-level encryption, and which key management model applies. Encryption in transit is handled by TLS between the application, the engine's database connection and clients calling the REST endpoint. Confirm the TLS version and cipher policy, who issues and renews certificates, and how key rotation is handled. Record these choices in the hardening scope so the team and any assessor can trace them.

Least-privilege service tasks

Each Java delegate behind a service task should call only the systems that step requires, using a credential scoped to that call. A shared service account across all delegates lets one flawed process model reach every downstream system. During design, map each service task to its target system and permitted operations, and review that map whenever a process changes. Credentials for external APIs usually belong in the secret manager. The team owns both the mapping and the grants.

Audit history and evidence needs

Flowable records history data according to the history level configured for the engine, and that setting determines which events, variables and task details are kept. Confirm which history types your level captures, how long records remain in the database, and who may read, export or purge them. Check whether the record answers your evidence questions, such as who approved a decision and when a process definition changed. Retention and archival periods are set by the team. An independent auditor decides whether the record is sufficient.

How to verify Flowable security hardening works and fails safely

The verification pass should prove two things: each hardening control refuses the request it was built to refuse, and the engine stops or rejects work when a control is missing rather than quietly running on an open path. Treat every expected result below as dependent on the Flowable version and configuration your team confirms for the target environment. Record the exact engine version, starter set, REST application build, database type and identity setup alongside each test run, because a result that holds on one configuration can differ on another. Start with negative tests against the REST API. An unauthenticated call to a process, task or history endpoint must return a refusal, not data. A call made with a valid token but without the role or scope that covers the resource must also be refused. Run these against the same gateway or Spring Security chain that production uses, not a developer profile with relaxed settings. Then test actuator access. The Flowable Spring Boot docs describe an actuator endpoint at /actuator/flowable for monitoring running processes, so request it from a host outside the monitoring network and confirm the request fails. Confirm the same from inside the network with a non-monitoring identity to show the access rule is role-based and not network-only. Next, test the policy on scripts and expressions. Attempt to deploy a process model that contains a script task or an expression the policy forbids. The deployment should be rejected at validation or deployment time. If a forbidden construct somehow deploys, attempt to start an instance and confirm it does not execute. For service tasks, withhold the scoped credential the task needs and confirm the task fails with an error the operations team can see, instead of calling the downstream system with a default or shared credential. Repeat this with the credential present but scoped to a different resource, which should also fail. The database tests need a dedicated account for the Flowable schema. Connect as that account and attempt actions outside its grant, such as dropping tables, reading another application's schema or altering grants. Each attempt should be denied by the database. Then run a secrets scan across process model files, deployed resources, application logs and the full repository history, not only the current branch. Any hit is a failure to fix and rotate, and the history scan matters because a secret removed from the latest commit remains in earlier ones. Finally, run a sample process from start to finish and confirm the history records your auditors expect, such as process instance start and end, activity and task events, and user actions, in the history level you configured. Also confirm the failure path: disable a control on a non-production copy and check that the engine refuses or halts work. Ask your implementation partner to write these as repeatable scripts with recorded expected results, and confirm each expectation against your confirmed version before accepting the environment.

Questions buyers ask about Flowable security hardening

What does Flowable security hardening cost, and what drives it?

The cost depends on how many engines, process, case and decision models, integrations and environments the hardening covers. The effort table on this page shows how each of these drivers moves the work. Most of the spend is one-time skilled engineering time for the review and changes. Recurring costs are mainly dependency updates for Spring and Jackson, periodic review and any ongoing support you choose. Ask for a quote that lists each workstream separately, the environments it covers, the testing included and what your team must supply. DeployOpen works to a fixed scope agreed in writing, so the quote follows from that scope. Ongoing support and continuous testing are available as separate retainers.

How long does Flowable security hardening take to complete?

Duration depends on the size of the deployment and how much of it is already documented. The main factors are the number of Flowable engines and REST endpoints in use, how many models need review, how many database types and environments are involved, and how identity and secret management connect to Flowable. A deployment with a complete model inventory and a named owner for each control generally moves faster than one where those facts must be gathered first. Ask for a timeline tied to the written scope, with milestones for review, changes, testing and handover. Also confirm which steps depend on your change windows or approval cycles, since those often set the pace more than the technical work does.

Can our internal team harden Flowable without an outside partner?

Yes, if the team has Spring Boot and database security skills and the model inventory is complete. Hardening touches the REST API, script tasks and expressions, database credentials and encryption, Spring and Jackson dependencies, audit history and least-privilege settings for service tasks, so engineers need working knowledge of each area. A complete inventory lists every deployed process, case and decision model, Java delegate, integration and service account, so nothing goes unreviewed. Teams that lack one of these skill areas often bring in a partner for a fixed review and then carry the changes in-house. Confirm staffing before deciding, because each control also needs a named owner who can approve changes and accept risk.

What does the hardening work need from our team to start?

The work needs access to the environments in scope, the model files and details of your identity and secret systems. Specifically, you should provide read access to the target environments and their configuration, the BPMN, CMMN and DMN files along with Java delegates and custom REST endpoints, the identity provider or directory details, and how secrets such as database credentials are stored and rotated. You also need a named owner for each control, someone who can approve changes on that control's behalf. Agree on test environments early so that changes to the REST API, script handling and database settings are verified before production. Missing owners often delay the schedule more than any technical issue.

Do Flowable's commercial products include security controls the open source engines lack?

Flowable states that its commercial products, including Flowable Work, Engage, Orchestrate and Design, are built on the same engines and add security controls, monitoring and governance. Its open source page describes this in general terms without listing each control, so the exact coverage must be confirmed with Flowable before you decide. Ask for a written list of the security controls, how each one is configured, whether it replaces or works alongside the controls your team builds, and what the license terms say about your environment. Because the open source engines run the same process logic either way, the hardening of your REST API, scripts, database and secrets still needs to be designed and checked in your own environment. Get that division of responsibility in writing.

Does DeployOpen issue security certifications for Flowable deployments?

No. DeployOpen does not issue certifications, audit reports or attestations. It prepares the system, its controls and the supporting evidence so that an independent auditor or certification body can assess them. For hardening, that means documenting configuration, access rules, change records and test results in a form an assessor can review. Your compliance lead and the assessor decide which standard or framework applies and what evidence they expect, so confirm those requirements early. Certification decisions rest with those independent bodies, and DeployOpen's role is preparation.

How DeployOpen scopes, hardens and hands over Flowable security work

DeployOpen approaches Flowable security hardening as a fixed-scope piece of work agreed in writing before it starts, covering the REST API, script and expression handling, database access, dependencies, audit history and service task permissions. The work runs inside your own infrastructure, and the written scope sets out what is tested, changed, documented and handed over.

How we scope

Inventory which Flowable engines, REST endpoints and deployment modes (embedded JAR, servlet container, Spring Boot or REST application) are in use.
Record where script tasks, expressions and custom delegates run, and which roles can deploy or edit process definitions.
Agree in writing which databases, credentials and dependency versions are in scope, including Spring and Jackson versions.

How we build

Restrict or review script tasks and expressions, and lock down deployment and definition management to named roles.
Protect the REST API with authentication and authorization, then test access to each endpoint with both valid and invalid roles.
Review database credential storage, encryption settings and least-privilege grants for service tasks, then test changes against a copy of your environment.

How we hand over

Deliver a written record of each configuration change, the tests run against it and any open risks the client must accept or fix.
Document how audit history is retained and who can read it, so your own team can verify the setup after handover.
Walk through the runbook for dependency updates and credential rotation with the engineers who will operate the system.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the fixed-scope hardening work.
Confirm with DeployOpen what a retainer covers for Flowable releases, including review of future Spring and Jackson dependency changes.
Ask for a quote that separates one-time hardening effort from any recurring retainer effort, so the ongoing cost is visible.

Flowable security hardening