Update qa tests to v1.0.12

[bitterpanda63]

Summary by Aikido

Security Issues: 0	🔍 Quality Issues: 1	Resolved Issues: 0

⚡ Enhancements

• Added thread-local bypassed context store and integrated bypass checks.
• Normalized IPv4-mapped IPv6 addresses and adjusted IPList matching logic.
• Normalized outbound domain hostnames using IDN and case-insensitive comparison.
• Introduced DangerousBodyException and enforced JWT size and depth limits.
• Updated QA workflow to use AikidoSec/firewall-tester-action v1.0.12.

^{More info}

[codecov]

Codecov Report

❌ Patch coverage is 56.33803% with 31 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../java/dev/aikido/agent_api/helpers/net/IPList.java	0.00%	14 Missing ⚠️
...erabilities/outbound_blocking/OutboundDomains.java	0.00%	8 Missing ⚠️
...ikido/agent_api/helpers/patterns/LooksLikeJWT.java	55.55%	4 Missing ⚠️
.../agent_api/helpers/extraction/StringExtractor.java	85.71%	2 Missing ⚠️
.../dev/aikido/agent_api/vulnerabilities/Scanner.java	0.00%	2 Missing ⚠️
...aikido/agent_api/storage/ServiceConfiguration.java	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[aikido-pr-checks]

report(...) now includes enforcement via BypassedContextStore.isBypassed(), mixing reporting and blocking. Rename/split the method or document the enforcement behavior.

Details

✨ AI Reasoning
​The report(...) method in the DNSRecordCollector previously performed DNS-related reporting and SSRF detection. The recent change adds a bypass check and conditional blocking via BypassedContextStore.isBypassed(), introducing enforcement behavior into a method named 'report'. This increases mixing of responsibilities and makes the method's purpose less self-evident, especially when callers expect reporting-only side effects. The problematic change occurs where the blocking condition was tightened to include the bypass check.

🔧 How do I fix it?
Use descriptive verb-noun function names, add docstrings explaining the function's purpose, or provide meaningful return type hints.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[aikido-pr-checks]

The if (!bypassed) block in report adds nesting around the main hostname-hit logic; invert the condition or use an early return/guard to flatten the method for clarity.

Show fix

Suggested change

	if (!bypassed) {
	// Bypassed IPs are trusted — don't report their outbound hostnames in heartbeats.
	if (!ports.isEmpty()) {
	for (int port : ports) {
	HostnamesStore.incrementHits(hostname, port);
	}
	} else {
	HostnamesStore.incrementHits(hostname, 0);
	}
	if (bypassed) {
	// Bypassed IPs are trusted — don't report their outbound hostnames in heartbeats.
	} else if (!ports.isEmpty()) {
	for (int port : ports) {
	HostnamesStore.incrementHits(hostname, port);
	}
	} else {
	HostnamesStore.incrementHits(hostname, 0);

Details

✨ AI Reasoning
​The report method now computes a bypassed flag and then wraps hostname hit-incrementing logic inside an if (!bypassed) else branch, increasing nesting. This buries the normal-path behavior and makes the flow harder to follow; using an early return or inverting the condition would flatten the logic and improve readability.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}