Security Threats & Anomalies

What you'll be able to do after this module

Read a security event and understand what it represents, assess its severity, and know the difference between a detected threat and an anomaly.

Security Threats

What Skytells flags as a security threat

Cognition monitors request patterns across your apps and flags behavior that looks unusual or adversarial:

These are detected automatically. No configuration required on your side.

How to read the Security Threats view

Open Cognition → Security Threats.

Each row shows:

• Type — the category of threat
• Severity — assessed impact if the threat were to succeed
• Time — when it was first detected and how long the pattern persisted
• Source — IP address or IP range where the activity originated
• Target — which app and endpoint received the traffic

Click a row to see the full event detail, including request counts, affected endpoints, and any enrichment data.

How severity is determined

Severity reflects the potential impact of the detected activity:

What to do when you see a threat

Critical or High:

1. Check whether the targeted endpoint was successfully reached. Look at the request target and check your logs.
2. If authentication failures are involved, check whether any accounts were actually accessed. Review recent successful authentications for the targeted resource.
3. If the source IP is hammering a specific endpoint, consider whether that endpoint needs additional rate limiting or authentication in your code.
4. Check the Errors view — if an attack is causing downstream failures, you'll see error spikes correlated with the event.

Medium:

1. Note the targeted endpoint. Scanners often probe for common vulnerable paths (/.env, /admin, /wp-login.php). If you're already returning 404, nothing further needed.
2. If the scanned path is something your app actually serves, verify it's properly authenticated and not leaking data.

Low:

1. Typically just worth noting. Review if the pattern persists or escalates.

Checking security events from the CLI

# Current security events
skytells cognition security

# Output as JSON for scripting
skytells cognition security --json

# Count how many high-severity events are active
skytells cognition security --json | jq '[.[] | select(.severity == "high")] | length'

# List just the critical events
skytells cognition security --json | jq '[.[] | select(.severity == "critical")]'

Anomalies

Anomalies are different from security threats. A threat is a recognized attack pattern. An anomaly is a statistical deviation from what Cognition has established as normal baseline behavior for your apps.

An anomaly might be completely benign — high traffic after a marketing launch, for instance. But anomalies are worth investigating because they indicate something changed.

Types of anomalies Cognition detects

Reading the Anomalies view

Open Cognition → Anomalies.

Each anomaly shows:

• Type — what kind of deviation was detected
• Severity — how significant the deviation is from baseline
• Duration — how long the anomalous condition persisted
• Affected app — which app exhibited the behavior

The difference between an anomaly and a problem

An anomaly is Cognition saying: "this is different from what I've seen before." It's not automatically saying "this is broken."

The pattern: look at what changed around the same time as the anomaly. The Errors view and Runtime Health together with Anomalies give you enough signal to tell a real incident from noise.

Checking anomalies from the CLI

# View current anomalies
skytells cognition anomalies

# JSON for scripting
skytells cognition anomalies --json

# Check whether any anomalies are currently active
ANOMALY_COUNT=$(skytells cognition anomalies --json | jq 'length')
if [ "$ANOMALY_COUNT" -gt 0 ]; then
  echo "Active anomalies: $ANOMALY_COUNT — review Cognition"
fi

Putting security and anomaly signals together

Security events and anomalies aren't always separate things. A DDoS attack shows up as both a security threat (high-volume requests from external sources) and an anomaly (traffic spike), and will likely cause an error spike too if it's overwhelming your app.

When you see multiple signals at once:

1. Check the timing. If a security event and an anomaly started at the same moment, they're almost certainly related.
2. Check whether the traffic volume overwhelmed something — look at Runtime Health for CPU/memory.
3. Check Errors for application-level failures triggered by the load or the attacker's requests.

The full picture comes from looking at multiple Cognition views together.

What you now know

Up next: Module 4 — Runtime Health & Live Events →