Vulnerability research across six first-party SaaS products

This paper documents the security research approach Cloudsoft Industries applies to six first-party SaaS products: MiPOS Digital, MasiBot, VitalSync, Rekurra, AquaGestión, and MiCarta Digital. The scope covers backend APIs, web and mobile applications, authentication and authorization flows, integrations, and infrastructure that we build and operate.

The boundary matters. This research is performed on systems we own or within explicitly authorized testing engagements. It does not describe testing against third-party or client systems without permission. We also withhold secrets, personal data, reusable exploit payloads, and operational details that could put a live instance at risk.

Research question

The question is not merely “did a scanner report something?” We ask whether a user, integration, or process with limited privileges can cross a trust boundary and affect confidentiality, integrity, or availability. In multi-tenant SaaS products, answering that question requires following the operation across the interface, API, business rules, asynchronous jobs, storage, and deployment configuration.

We prioritize paths where a failure would have material impact:

• Tenant isolation. We test whether manipulated identifiers, searches, exports, or internal endpoints can expose or modify another organization's data.
• Authentication and recovery. We review session handling, token rotation, credential reset, revocation, and role changes.
• Object- and function-level authorization. We separate access to a screen from the server-side permission required to perform the operation.
• Sensitive business flows. We assess payments, webhooks, user provisioning, reconciliation, notifications, and administrative actions.
• Configuration and infrastructure. We review secrets, headers, public storage, service permissions, logs, and environment separation.

Portfolio and surfaces

Product	Surfaces in scope	Priority boundaries
MiPOS Digital	API, back office, web and mobile clients	Roles, commercial operations, business isolation, and integrations
MasiBot	API, automations, and console	Tool permissions, conversation data, and automated actions
VitalSync	API and operational applications	Sensitive data, sessions, traceability, and privileges
Rekurra	API, webhooks, and management panel	Event integrity, idempotency, authorization, and secrets
AquaGestión	API and web application	Account separation, administrative operations, and data exports
MiCarta Digital	Web application, API, and infrastructure	Content publishing, administration, and deployment configuration

This table defines research surfaces; it does not claim that every product contains a specific vulnerability. We assign severity only after reproducing a condition and demonstrating impact in a controlled environment.

Repeatable method

1. Inventory and trust model. We enumerate assets, roles, inputs, outputs, integrations, and tenant boundaries. A route absent from the inventory cannot be defended systematically.
2. Abuse hypotheses. We turn each boundary into testable questions: can a basic role invoke an administrative function, can a webhook be replayed, or can a predictable identifier expose another tenant's data?
3. Manual and assisted testing. We combine code and configuration review, API testing, state manipulation, and bounded automation. Scanners expand coverage; they do not issue the verdict.
4. Minimal reproduction. We retain the request, preconditions, observed response, impact, and expected control. Another engineer must be able to reproduce the finding without an oral explanation.
5. Classification. We use FIRST CVSS v4.0 as a shared technical language, then add product context such as data sensitivity, cross-tenant reach, required privileges, and recoverability.
6. Remediation and retest. A finding is not closed when code merges. We repeat the original reproduction, test related variants, and verify that the change did not weaken another boundary.

Evaluation criteria

Coverage is grounded in open, reviewable references. For APIs we use the risk classes in the OWASP API Security Top 10 2023. For web application and service controls we use requirements from OWASP ASVS 5.0.0. Planning, evidence handling, and reporting follow the principles in NIST SP 800-115.

These references do not replace product analysis. A common technical weakness can become critical when it crosses tenants or affects money, identity, or sensitive data. It can also have lower impact when verifiable compensating controls exist.

Evidence, disclosure, and limits

For each confirmed condition, we maintain a record of the asset, version, preconditions, reproduction steps, evidence, impact, severity, remediation owner, and retest result. Sensitive evidence remains in the relevant private repository. This paper makes the method and scope public without turning a defensive report into an exploitation guide.

We do not assign a CVE to an internal finding by default. A CVE requires a vulnerability suitable for coordinated public disclosure in a product relevant to other parties. Nor do we treat the absence of known incidents as proof of security. The stronger signal is repeatable research, remediation traceability, and independent patch validation.

Operational outcome

The result is a continuous loop: discover, reproduce, prioritize, remediate, and retest. When we provide controlled application security testing for an authorized development, we apply the same discipline with rules of engagement, permitted assets, testing windows, and stop conditions defined before work begins.

Researching our own products lets us exercise the full process. The same team can trace a condition from an HTTP request or mobile state change through the domain rule and infrastructure to the regression test that prevents recurrence. The companion paper explains how we validate a patch before closing a finding.