NIST National Vulnerability Database Integration - API (CVE only) - getting partially failed

Maloy Banerjee1
Tera Expert

Hi Team,

 

The NIST National Vulnerability Database Integration - API (CVE only) integration job has partially failed for me.

 

Approximately 90% of the Integration process run is marked as "Completed" and 10 % is marked as "Failed" with the error code - "Attempting retry with process VINTPRC0001369. Error: Invalid response code received from NVD: 403. Encountered process error running the integration."

 

Question: Is it normal behavior to get some of the integration processes to fail?

 

Confusion/Issue: When I compare the count of records in the source table (sn_vul_nvd_cves_import) and the target table (sn_vul_nvd_entry), the number of records in the Source Table is more than the number of records in the Target table.

 

Can you please help, how can we fix this issue so that the result is 100% success?

 

MaloyBanerjee1_0-1701354038205.png

 

Regards,

Maloy Banerjee

 

1 ACCEPTED SOLUTION

joe_harvey
ServiceNow Employee
ServiceNow Employee

Hey Maloy,

 

I have seen this in a couple of instances that started using the NVD v2 endpoint and have not yet come across a solution.  On a positive note, based on what is visible in the VINTPRC lines that you showed, it looks like Retry logic was able to process the requests that failed. You can validate this by looking into the Parameters and verifying that there is a State=Complete record for each one that Failed.

 

If you are not using an NVD API Key, adding one may help. Andy does a great job explaining the process of adding an API Key to the NVD Integration: https://www.servicenow.com/community/secops-vr-forum/nist-national-vulnerability-database-integratio... [ hat tip: @andy_ojha !]

 

Regarding the count of records in the Source vs. Target tables, have you verified that there are no duplicates in the Source table?

 

I hope that this helps,

--Joe

View solution in original post

4 REPLIES 4

joe_harvey
ServiceNow Employee
ServiceNow Employee

Hey Maloy,

 

I have seen this in a couple of instances that started using the NVD v2 endpoint and have not yet come across a solution.  On a positive note, based on what is visible in the VINTPRC lines that you showed, it looks like Retry logic was able to process the requests that failed. You can validate this by looking into the Parameters and verifying that there is a State=Complete record for each one that Failed.

 

If you are not using an NVD API Key, adding one may help. Andy does a great job explaining the process of adding an API Key to the NVD Integration: https://www.servicenow.com/community/secops-vr-forum/nist-national-vulnerability-database-integratio... [ hat tip: @andy_ojha !]

 

Regarding the count of records in the Source vs. Target tables, have you verified that there are no duplicates in the Source table?

 

I hope that this helps,

--Joe

Hi Joe,

 

Thank you for your response. I still have to validate that there are no duplicates in the source table (I need some time as there are approx. 100K records). But your statement - "it looks like Retry logic was able to process the requests that failed" helped me to understand what I needed.

Also, the end result is the integration is successful.

MaloyBanerjee1_0-1701419812386.png

 

I will mark your answer as correct.

 

 

Thanks,

Maloy

 

Hi Maloy,

 

may you specify better how you solved the issue, as we are facing the same problem ?

Thanks and regards

 

Pietro

Hi Pietro,

 

The main cause of the issue in my case was the ACL in sys_attachment table. My client configured the Delete ACL in sys_attachment table in such a manner so that only users with security_admin can delete the attachments. Therefore, once I by-passed the ACL, I didn't find the issue been recreated.
Also, you need to check for errors like "Attempting retry with process VINTPRC0001369. Error: Invalid response code received from NVD: 403. Encountered process error running the integration."  This means access forbidden. So don't get confused by this error.

 

 

Regards,

Maloy Banerjee