# Known Risks & Limitations This page states, plainly, the **foreseeable security risks and design limitations** of Flopsar and what an operator must do to mitigate them. Informing users of known and foreseeable risks is an essential requirement of the Cyber Resilience Act (Annex II, point (e)); this page is how we discharge it. None of the items below are defects. They are the inherent consequences of what Flopsar does — observing live production JVMs from inside their trust boundary — together with the points where the product deliberately leaves a control in the operator's hands. Read this page alongside the Hardening Checklist; most mitigations are consolidated there. ## How to read this page Flopsar implements substantial controls (authenticated and encrypted agent sessions, RBAC, a tamper-evident audit trail, data masking, and more). What remains after those controls are applied are **residual risks**, and several of them can only be closed by the operator's deployment choices. Each item below pairs the risk with the action that addresses it. ## The agent runs inside the monitored application The agent executes **in-process** inside each monitored JVM. This is what makes deep diagnosis possible, but it also means that overly broad instrumentation, an unsuitable monitoring profile, or a faulty extension can affect the **performance, stability, or availability** of the application being observed. **Mitigation.** Test profiles and instrumentation changes in a non-production environment first; scope instrumentation to what you need; restrict who holds profile-deployment and instrumentation permissions; and monitor application overhead after changes. Deploy agent and profile changes within the application's normal maintenance windows. ## Capture of sensitive or personal data To diagnose faults, Flopsar can capture method arguments, exceptions, and parameters from running applications. Depending on what the monitored application processes, these may contain **secrets or personal data**. Flopsar provides **data masking** to reduce this exposure, but it is important to understand precisely what it does: * Masking is applied **server-side, at ingest, before values are written to storage**, so for matched values the original is never persisted. * Masking is **pattern-based** (regular expressions). It ships with default patterns for common personal data and reduces — but does not guarantee elimination of — sensitive values. Anything that does not match a configured pattern passes through unchanged. * Masking currently applies to captured **arguments**. **Exception payloads are not masked**, so sensitive content carried in exceptions must be controlled by other means. * Because masking happens at ingest, **raw data still transits from the agent to the server** (over the encrypted channel) before masking occurs, and the server processes the unmasked value transiently before storing the masked form. **Mitigation.** Configure and review masking patterns for your data; use **filters** to limit what is captured in the first place (the most reliable control, and the one that also covers exceptions); keep `max_ext_size` bounded; and set a **retention period** so captured data is not kept longer than needed. Restrict the permissions that allow viewing captured arguments/exceptions, and rely on the audit trail, which records access to that data and changes to masks. See Data Protection and Privacy & Data Handling. ## Plugins and extensions execute custom code Plugins/extensions run **custom bytecode inside the monitored JVMs**. This is a powerful capability and therefore a high-impact one: a malicious or defective extension can affect the monitored application and the data Flopsar handles. It is both a supply-chain and an insider-risk surface. **Flopsar-provided plugins are open source.** The plugins and extensions published by Flopsar Technology are available publicly on GitHub **together with their full source code**, so you can review exactly what they do, build them from source, and verify the artifact you deploy against that source. This substantially reduces supply-chain uncertainty for the official plugins. See Agent Extensions for the repository location. The residual risk therefore concentrates on **custom plugins you develop in-house and any third-party extensions** that are not published by Flopsar. **Mitigation.** Restrict the permission to upload/manage plugins to a small set of trusted administrators; review extensions before deployment and prefer building official plugins from their published source; source any third-party extension only from trusted parties and review it as you would any code that runs in production; and monitor the audit events for plugin uploads and deletions. ## The agent–server channel relies on a per-application pre-shared key The agent–server channel is authenticated and encrypted with a per-application **pre-shared key (PSK)** rather than TLS. The PSK is a long-lived secret that must be present on each monitored host. If an agent host is compromised, its PSK could be used to impersonate that agent to the server. **Mitigation.** Protect the PSK with restrictive file permissions on the agent host, treat it as a secret, rotate it if a host may have been exposed, and keep the agent network segment trusted. The handshake provides forward secrecy for recorded traffic, so a later PSK compromise does not retroactively decrypt past sessions. See Cryptography & Key Management. ## Collected data at rest is not encrypted by the application Flopsar seals agent PSKs with the master key and stores user passwords as salted scrypt hashes, but the **collected performance data, captured arguments, and exceptions are stored without application-level encryption**. Their confidentiality at rest depends on the controls of the host operating system and storage. Data masking reduces the sensitive content persisted for matched **argument** patterns, but it is pattern-based and does not currently cover exception payloads, so it is not a substitute for storage-level encryption. **Mitigation.** Run the server on **encrypted storage** (full-disk or volume encryption), restrict filesystem permissions on the data directory to the service account, protect and encrypt backups, and minimize what is captured and retained through masking, filtering, and retention settings. See Data Protection. ## Secure defaults must be enabled by the operator Several controls are present but **not enabled or hardened by default**, so an unhardened deployment is weaker than a hardened one: * The local-account **password policy is disabled by default**. * There is **no built-in automatic lockout or rate-limiting** for failed logins. * TLS on the **OTLP/gRPC** endpoint is off by default. * A **self-signed certificate** may be used until you install a CA-issued one. * LDAP offers a `skip_verify` option that disables certificate verification. **Mitigation.** Work through the Hardening Checklist: enable the password policy, install a trusted certificate, enable TLS on OTLP where telemetry leaves the host (or disable OTLP if unused), use LDAPS with certificate verification (never `skip_verify` in production), and place the management interface behind a reverse proxy or VPN that provides rate-limiting and IP restrictions. ## Session revocation is coarse-grained API sessions are **stateless JSON Web Tokens**. A token carries the user's permissions as resolved at sign-in and remains valid until it expires (a fixed lifetime) unless invalidated. Consequently, a permission reduction or deauthorization is **not instantaneous** within an active session. **Mitigation.** To cut off a specific user immediately, **lock the account**. To invalidate **all** sessions at once (for example during incident response), **restart the server**, which rotates the in-memory token-signing secret. Plan your expectations around the token lifetime. See Authentication, Authorization & Identity. ## Detecting audit-log truncation requires external anchoring The audit trail is a tamper-evident hash chain: modification, deletion, and reordering **within** the file are detectable. However, removing the most recent records (**tail truncation**) produces a still-internally-consistent shorter chain, which can only be **proven** inconsistent if you have an independent record of a later state. **Mitigation.** Forward the audit log off the host and **anchor the chain head hash** periodically in an independent, write-once location or your SIEM, so a later state of the chain can always be checked against a known-good reference. See Logging, Monitoring & Audit Trail. ## Availability and capacity are operator-managed The server is the central component of a deployment. Its availability, capacity, and the growth of its data store are the operator's responsibility. **Mitigation.** Monitor server health and disk usage, configure **retention/ archiving** to bound storage growth, and maintain **backups** of the data directory and the `ssl` directory (configuration, certificates, master key). See Operations and Updates & Patch Management for backup-before-upgrade guidance. ## Intended operating environment Flopsar is designed to run inside a **trusted, segmented** environment, not to be exposed directly to the public internet. Deploying it outside its intended environment increases every risk above. **Mitigation.** Follow the reference topology in Deployment Models & Operational Environment: segment the network, keep management and agent interfaces off untrusted networks, and front the management interface with appropriate controls. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.flopsar.com/7/security/known-risks-and-limitations.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.