• X
• Mastodon
• LinkedIn
• Facebook

src/components/pipeline/__tests__/WebSocketProgressBar.test.tsx (1)

243-243: Avoid getAllByText(...)[0] for these assertions.

Picking the first match just bakes current DOM order into the tests, so another "connecting", "sent", or "received" label will make them flaky again. Scope the assertion with within(...), or target a role/test id for the specific element under test instead.

As per coding guidelines, "Test component behavior, not implementation details" and "Use @testing-library/react for component testing with screen queries and accessibility queries."

Also applies to: 732-733

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/components/pipeline/__tests__/WebSocketProgressBar.test.tsx` at line 243,
The test in WebSocketProgressBar.test.tsx uses
expect(screen.getAllByText(/connecting/i)[0]) which relies on DOM order and is
flaky; update the assertion to scope the query to the specific element (use
within(...) on the component/container or target an accessible role/testid)
instead of getAllByText(...)[0]; replace similar occurrences around lines
732-733 as well and use functions like within(renderedContainer).getByText(...)
or screen.getByRole/getByTestId for the specific progress-label element so the
test asserts the intended element reliably.

src/lib/services/performance-optimizer.ts (1)

63-64: Redundant counter initialization.

The counters are initialized at declaration (lines 63-64) and again in the constructor (lines 85-86). The field initializers are sufficient; the constructor assignments can be removed.

♻️ Suggested cleanup

   constructor(config: Partial<OptimizationConfig> = {}) {
-    this.totalCacheAccesses = 0
-    this.cacheHitsCount = 0
     this.config = {

Also applies to: 85-86

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/services/performance-optimizer.ts` around lines 63 - 64, Remove the
redundant re-initialization of the counters in the constructor: the fields
totalCacheAccesses and cacheHitsCount are already initialized at declaration, so
delete their assignments inside the constructor (look for the constructor method
in performance-optimizer.ts that sets totalCacheAccesses = 0 and cacheHitsCount
= 0) and leave the field initializers as the single source of initialization.

.github/codeql/custom-queries/ehr/unencrypted-ehr-data.ql (1)

42-51: Pre-existing gap: no flow check between data and the transmission call.

The query checks that isDataTransmissionCall(call) and isEHRData(data) hold independently, but there's no constraint ensuring data actually flows into arguments of call. This could produce false positives where an unrelated EHR variable exists in the same file as a transmission call.

Consider adding a flow check, for example:

 from CallExpr call, DataFlow::Node data
 where
   isDataTransmissionCall(call) and
   isEHRData(data) and
+  data.flowsTo(DataFlow::exprNode(call.getAnArgument())) and
   not exists(CallExpr encryptCall |
     encryptCall.getCalleeName().matches("%encrypt%") and
     data.flowsTo(DataFlow::exprNode(encryptCall.getAnArgument()))
   )

This is a pre-existing issue unrelated to the current change—flagging for awareness.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/unencrypted-ehr-data.ql around lines 42 -
51, The query currently treats isDataTransmissionCall(call) and isEHRData(data)
independently, causing false positives because it doesn't ensure the EHR data
actually flows into the transmission call; modify the where-clause to require a
data flow from data into an argument of the transmission call (e.g., add a
condition using data.flowsTo(DataFlow::exprNode(call.getAnArgument())) or
equivalent to assert data flows to one of call's argument nodes), keeping the
existing encryptCall exclusion logic intact (references: CallExpr call,
DataFlow::Node data, isDataTransmissionCall, isEHRData, encryptCall).

.github/codeql/custom-queries/ehr/ehr-security-patterns.ql (1)

17-46: Design trade-off: merged configuration reduces precision.

Combining the two original configurations (InsecureEHRConfig and UnsafeEHRAccess) into a single EHRConfigSig module means all sources can flow to all sinks:

• EHRCredentialSource → EHR request arguments (could be legitimate credential usage)
• RemoteFlowSource → logging calls (could be intentional request logging)

This may increase false positives compared to the original separate configurations. If this is intentional for simplicity, consider documenting the trade-off. If high precision is needed, you could use separate configuration modules or add additional constraints in isSink to filter source types.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/ehr-security-patterns.ql around lines 17 -
46, The merged EHRConfigSig loses precision by allowing both EHRCredentialSource
and RemoteFlowSource to match all sinks; split the config back into two modules
(InsecureEHRConfig and UnsafeEHRAccess) or tighten EHRConfigSig.isSink to check
source type before matching sinks (e.g., only allow EHRCredentialSource to match
logging/URL sinks and only allow RemoteFlowSource to match remote-request
sinks), using the existing symbols isSource, isSink, EHRCredentialSource,
RemoteFlowSource, and EHREndpoint to implement the source-specific constraints.

.github/codeql/custom-queries/ehr/ehr-security-patterns.ql (1)

74-82: ⚠️ Potential issue | 🟠 Major

Logic flaw in EHR request sink pattern remains unaddressed.

The condition endpoint.flowsTo(sink) requires the EHR endpoint URL to flow to the same argument that is the taint sink. This misses the primary attack vector: tainted remote data flowing to a different argument (e.g., request body) of a call targeting an EHR endpoint.

Example not detected:

const url = "https://example.com/fhir/Patient";  // EHREndpoint
const userInput = req.body.data;  // RemoteFlowSource (tainted)
fetch(url, { body: userInput });  // userInput in body, url in first arg

Proposed fix

     // Sinks for unsafe access: remote data used in requests to EHR endpoints
     exists(DataFlow::CallNode call |
       (
         call.getCalleeName().matches("%request%") or
         call.getCalleeName().matches("%fetch%") or
         call.getCalleeName().matches("%axios%")
       ) and
       sink = call.getAnArgument() and
-      exists(EHREndpoint endpoint | endpoint.flowsTo(sink))
+      exists(EHREndpoint endpoint | endpoint.flowsTo(call.getAnArgument()))
     )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/ehr-security-patterns.ql around lines 74 -
82, The current pattern only matches when the EHREndpoint URL flows into the
exact same call argument identified as sink; update the predicate so we require
the EHREndpoint to flow to some call argument (e.g., introduce an argument
variable endpointArg via call.getAnArgument()/call.getArgument(i)) and allow the
tainted sink to be a different argument (sink = call.getAnArgument()) by
replacing endpoint.flowsTo(sink) with an exists(endpointArg |
call.getAnArgument() = endpointArg and endpoint.flowsTo(endpointArg) and not
endpointArg.equals(sink)) so the rule detects cases where the URL is one
argument and tainted remote data flows into another (body/header) argument.

.github/codeql/custom-queries/ehr/ehr-security-patterns.ql (2)

25-29: Log sink pattern is overly broad.

The regex (?i).*log.* matches any function containing "log" anywhere in the name, including unrelated functions like catalog, dialogue, analog, or prologue. This will cause false positives.

🔧 Suggested improvement with word boundary matching

   predicate isSink(DataFlow::Node sink) {
     exists(DataFlow::CallNode call |
-      call.getCalleeName().regexpMatch("(?i).*log.*") and
+      call.getCalleeName().regexpMatch("(?i).*(\\blog\\b|logger|logging|console).*") and
       sink = call.getAnArgument()
     ) or

Alternatively, match specific known logging patterns:

call.getCalleeName().regexpMatch("(?i)(log|warn|error|info|debug|trace|console)")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/ehr-security-patterns.ql around lines 25 -
29, The isSink predicate is too broad because
call.getCalleeName().regexpMatch("(?i).*log.*") will match any name containing
"log"; narrow this by changing the regexp in isSink (the DataFlow::CallNode /
call.getCalleeName() check) to either use word-boundary matching or enumerate
common logging identifiers (e.g., use a pattern like
(?i)\b(log|warn|error|info|debug|trace|console)\b or an explicit alternation of
known logging functions) so only actual logging calls are treated as sinks.

---

34-39: EHR endpoint sink only matches literal URL strings.

call.getAnArgument().getStringValue() only returns non-null for string literals, so dynamically constructed URLs won't be detected:

const baseUrl = config.ehrEndpoint;  // Won't match
fetch(baseUrl + "/fhir/Patient", data);

This is an acceptable precision trade-off, but consider adding a supplementary pattern for well-known URL variables/properties if broader coverage is needed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/ehr-security-patterns.ql around lines 34 -
39, The current DataFlow::CallNode sink logic relies on
call.getAnArgument().getStringValue(), which only matches string literals and
misses dynamically constructed URLs; update the query to add a supplementary
pattern that matches well-known EHR URL variables/properties and non-literal
argument sources (e.g., check the argument's value/source rather than only
getStringValue()), for example add an alternative exists branch that inspects
call.getAnArgument().getAValue()/getAnArgument().getASource() or matches
identifier/property names like "ehrEndpoint", "baseUrl", "config.*" and still
applies the same url.regexpMatch and callee regexpMatch checks so
dynamically-built endpoints (config.ehrEndpoint + "/fhir") are flagged.

.github/codeql/custom-queries/ehr/unencrypted-ehr-data.ql (1)

17-22: Source detection using toString() is unreliable for taint tracking.

Using source.asExpr().toString().toLowerCase() matches based on source code representation (variable names, string literals), which is fragile:

• False positives: Variables like catalogItem match due to containing "clinical" substring patterns
• False negatives: Aliased or renamed EHR data won't be detected

Consider using semantic patterns like property accesses on known EHR objects or API return values instead.

🔧 Suggested improvement using semantic sources

   predicate isSource(DataFlow::Node source) {
-    exists(string s |
-      s = source.asExpr().toString().toLowerCase() and
-      s.regexpMatch(".*(patient|health|record|ehr|fhir|clinical).*")
-    )
+    // Match property reads from EHR/FHIR objects
+    exists(DataFlow::PropRead read |
+      read = source and
+      read.getPropertyName().regexpMatch("(?i).*(patient|health|record|ehr|fhir|clinical).*")
+    )
+    or
+    // Match return values from EHR API calls
+    exists(DataFlow::CallNode call |
+      call = source and
+      call.getCalleeName().regexpMatch("(?i).*(getPatient|fetchRecord|readEHR|getFHIR).*")
+    )
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/codeql/custom-queries/ehr/unencrypted-ehr-data.ql around lines 17 -
22, The predicate isSource currently relies on
source.asExpr().toString().toLowerCase() and regexpMatch which is fragile;
replace this string-based detection with semantic source patterns by matching
expression/flow node kinds (e.g., DataFlow::ExprSource, FieldAccess,
MemberAccess, MethodCall) and known EHR API identifiers or property names (for
example check receiver and field names like "patient", "ehr", "fhir" on
MemberAccess/FieldAccess nodes or known API call targets) so taint sources are
identified by AST/semantic node types rather than textual toString() values;
update the isSource predicate to inspect source.asExpr() node kind and its
resolved member/identifier names instead of using toString()/regexpMatch.