Back to blog

Baseline-first security: why behavior beats blocklists

·KA13 Team

Traditional mobile security operates on a simple principle: maintain lists of known-bad actors and block them. Signature-based antivirus, domain blocklists, malicious app databases. They all follow the same pattern: match what is happening now against a catalog of past threats.

This approach works reasonably well for known threats. But it has a fundamental blind spot: what happens when a legitimate app you already trust starts behaving badly?

The limitation of blocklists

Consider a popular photo editing app you've used for months. It's on the Play Store, has millions of downloads, and has never triggered any security warnings. Then one day, after an update, it starts:

  • Requesting location permissions it never needed before
  • Making network connections to unfamiliar domains at unusual times
  • Running background services that were not there in previous versions

Traditional blocklist-based security will not catch this. The app is not in any malware database. The domains it is connecting to might be legitimate infrastructure services. The permissions are all "legal" according to Android's security model.

By the time someone reports suspicious behavior and the app gets added to a blocklist, it may have already exfiltrated data from thousands of users.

Enter baseline-first security

Baseline-first security flips the detection model. Instead of asking "is this behavior on a list of bad things?", it asks "is this behavior different from what we established as normal for this app?"

Here is how Baselyt implements this:

  1. Learning phase: When you first install an app (or when Baselyt starts monitoring), we observe and record its behavior over time: network patterns, permission usage, background activity.
  2. Baseline establishment: After collecting sufficient data, we build a statistical profile of what "normal" looks like for that specific app on your specific device.
  3. Drift detection: Every subsequent action the app takes is compared against this baseline. Meaningful deviations trigger alerts.
  4. Explainable alerts: When drift is detected, we show you exactly what changed: "This app used to make 3 network requests per hour to api.photoapp.com. Now it is making 47 requests per hour to tracker-network.xyz."

Why this catches what blocklists miss

Baseline-first detection excels at catching:

  • Compromised legitimate apps: When an app you trust gets taken over by malicious actors
  • Gradual feature creep: Apps that slowly add tracking or data collection over time
  • Supply chain attacks: When a dependency used by your app gets compromised
  • Zero-day malicious behavior: New attack patterns that are not in any signature database yet

The challenge: handling updates

The biggest challenge with baseline-first security is distinguishing between malicious drift and legitimate app updates. When an app adds a new feature, its behavior will naturally change.

Baselyt handles this through:

  • Version-aware baselines: We track which behaviors correspond to which app version
  • Learning periods after updates: When an app updates, we allow a grace period for new patterns to establish
  • User feedback loops: You can mark changes as "approved" or "suspicious", which tunes future detection
  • Context-aware scoring: We weight changes based on their security significance. Adding a social sharing feature is very different from suddenly requesting location access

Conclusion

Blocklists are not going away, and they still serve a purpose for known threats. But they are fundamentally reactive. They can only protect against yesterday's attacks.

Baseline-first security is proactive. It does not need a catalog of every possible malicious behavior. It just needs to know what is normal for your apps, and alert you when that changes in security-meaningful ways.

That is the core philosophy behind Baselyt: learn what is normal, contain what is not.