helm install elasticsearch elastic/elasticsearch \

  --version 8.5.1 \

  --set replicas=1 \

  --namespace default



helm install persistence-elastic \

oci://[ghcr.io/securecodebox/helm/persistence-elastic](http://ghcr.io/securecodebox/helm/persistence-elastic) \

--version 5.2.0 \

--namespace default



kubectl apply -f - <<EOF

apiVersion: "[execution.securecodebox.io/v1](http://execution.securecodebox.io/v1)"

kind: Scan

metadata:

name: trivy-test

spec:

scanType: "trivy-image"

parameters:

 - "nginx:latest"

EOF



kubectl logs -l [app.kubernetes.io/name=persistence-elastic](http://app.kubernetes.io/name=persistence-elastic)





Expected Behavior

The persistence hook should successfully index findings to Elasticsearch 8.x, just as it does with Elasticsearch 7.x.



Actual Behavior

The persistence hook crashes with TypeError: Cannot read properties of undefined (reading 'errors') when attempting to process the Elasticsearch bulk API response.



Root Cause Analysis

The issue is in the hook's handling of the Elasticsearch bulk API response. The response format changed between Elasticsearch 7.x and 8.x:



Elasticsearch 7.x response:

{

body: {

 errors: false,

 items: [...]

}

}



Elasticsearch 8.x response:

{

errors: false,

items: [...]

// No .body wrapper

}



Current hook code (approximately line 110 in hook.js):

const { body: bulkResponse } = await client.bulk({ refresh: true, body });



if (bulkResponse.errors) {  // ← TypeError here when bulkResponse is undefined

console.error("Bulk Request had errors:");

console.log(bulkResponse);

}





When using Elasticsearch 8.x, the destructuring { body: bulkResponse } results in bulkResponse being undefined because the response doesn't have a .body property. This causes the TypeError when trying to access bulkResponse.errors.



Proposed Solution

Implement a backwards-compatible fix that works with both Elasticsearch 7.x and 8.x:



// Proposed fix for hook.js around line 110

const response = await client.bulk({ refresh: true, body });



// Support both ES 7.x (response.body) and ES 8.x (response directly)

const bulkResponse = response.body || response;



if (bulkResponse.errors) {

console.error("Bulk Request had errors:");

console.log(bulkResponse);

}



This change:



✅ Works with Elasticsearch 7.x (uses response.body)

✅ Works with Elasticsearch 8.x (uses response directly)

✅ No breaking changes to existing functionality

✅ Simple one-line fix

✅ Follows the pattern used by Elasticsearch's official Node.js client migration guide

Environment

SecureCodeBox Version: 4.9.0

persistence-elastic Hook Version: 5.2.0

Elasticsearch Version: 8.5.1 (issue occurs), 7.17.3 (works correctly)

Kubernetes Version: 1.28

Installation Method: Helm





Workaround

Currently, the only workaround is to downgrade Elasticsearch to version 7.17.x:

helm install elasticsearch elastic/elasticsearch \

--version 7.17.3 \

--namespace default





However, this prevents users from:



Using Elasticsearch 8.x features

Following Elasticsearch's recommended upgrade path

Receiving security updates for Elasticsearch 8.x

Additional Context

Affected scanners: All scanners that produce findings (Trivy, Semgrep, Nmap, custom scanners)



Chunk size impact: The error occurs when processing chunks of findings. In our testing:



0 findings: Hook succeeds (no bulk operation)

1-50 findings: Hook crashes on first bulk operation

50+ findings: Hook crashes on first chunk (50 findings per chunk)



related Elasticsearch migration documentation:



[Elasticsearch 8.0 Breaking Changes](vscode-file://vscode-app/c:/Users/GKY24/Downloads/VSCode-win32-x64-1.104.1/resources/app/out/vs/code/electron-browser/workbench/workbench.html)

[Elasticsearch Node.js Client Migration](vscode-file://vscode-app/c:/Users/GKY24/Downloads/VSCode-win32-x64-1.104.1/resources/app/out/vs/code/electron-browser/workbench/workbench.html)



Request

Please consider implementing the proposed backwards-compatible fix in the next release of the persistence-elastic hook. This will enable users to use Elasticsearch 8.x while maintaining compatibility with 7.x installations.



Thank you for maintaining this excellent project! 🙏