Vulnerabilities or scan findings: build for Vulnerability Response

• Your product finds infrastructure vulnerabilities, or produces application-security findings (DAST, SAST, SCA and more), container findings or configuration test results that customers triage in ServiceNow.
• Or you sell vulnerability intelligence, such as exploit context for CVEs, that enriches the vulnerability data customers already hold.
• Your customers run Vulnerability Response, or the application your findings belong in.
• You want findings tied to configuration items in the customer’s CMDB.
• Check first whether ServiceNow already ships an integration for your product; it builds its own for several large scanners, so yours has to add something theirs doesn’t.

• Customers need the application your findings go into: Vulnerability Response (Application Vulnerability Response is part of it), Container Vulnerability Response or Configuration Compliance. In the customer’s instance, Application Manager can show your app as “Not Licensed”; ServiceNow lists “A required dependency is not licensed” among the possible causes.
• Linking findings to CIs relies on the customer’s own CMDB data.
• If your app is free, list it as type Integration: the Store says free apps of type Integration “are exempted from the custom table count and do not require custom table entitlement.” A free app of any other type uses each customer’s custom-table entitlement.

• Build Program membership, and vendor instances that can run the Security Operations plugins you need. Confirm plugin access before you plan the build.
• Test data that exercises your real finding types and volumes, not demo records.
• A plan for USEM: build against the version customers will run after the Brazil release.
• ServiceNow’s Security Operations integration development guidelines, which say: “Any requirements for application certification or guidelines given in the Technology Partner Program literature supersede any information in this guide.”

Certification reviews your documents as well as your app, and in our experience it’s the part most teams miss. ServiceNow’s certification guide says “Certification has two tracks”: an app review and a listing review.

• For the app review, ServiceNow asks for a “Design Document (for certification team only)”, a “Test Plan with results (for certification team only)” and an “Installation Guide (customer facing)”. Write the design document and test plan on ServiceNow’s templates; it provides a recommended template for the installation guide too.
• For the listing review, your Store listing “consists of marketing documentation, demo videos, and other resources”, and the team inspects it for “Accuracy” and “Adherence to branding guidelines”.

ServiceNow lists “How well you documented your architecture in your Design Documentation” among the things that decide how long certification takes. The calendar gives the documents a week of their own.

Plan on roughly 11–17 weeks (8–13 with a team that already knows the framework) from the start of design to a Store listing. The framework takes time to learn, and design is where that time goes.

Not in ServiceNow’s Build Program yet? Add admission first: in our experience it takes 2–6 weeks, because ServiceNow reviews each application.

Weeks for design, build, documents and any programme steps come from our own projects. The review range is ServiceNow’s: certification “typically requires 3-5 weeks”, and no service level is published.

• Writing to Vulnerability Response tables directly instead of through the integration framework. For the move to USEM, ServiceNow says: “There should be no changes to custom integrations leveraging the integration framework.”
• API credentials stored in properties or scripts instead of credential records.
• Large scheduled imports without batching; performance is one of the review areas.
• Missing ACLs on custom tables, and client-callable script includes without ACLs, both in ServiceNow’s ten most-failed checks.

• Maintenance is a release certification for each family release: retest on the new release and submit a revised test plan. ServiceNow’s Upgrade Policy says it “generally releases two new release families per year”. Any change to the app is a recertification, planned as new work. Retest when ServiceNow updates its Security Operations applications.
• Track the USEM change: customers on Brazil or later will be on USEM.

• What data leaves their instance, and in which direction.
• Which service account the integration runs as. Expect them to reject admin; use a dedicated integration role.
• Whether it’s certified, and what that covers. Certification is strict on most security and performance issues, but it isn’t a full security audit, and the Store’s terms still leave use at the customer’s own risk. Have your own security answers ready.