what the vendor says
States plainly that Oracle 'does not support the use of NetSuite IP addresses to access or manage access to any NetSuite services', that outbound addresses are 'not documented in the NetSuite Help Center or in SuiteAnswers', and that *.netsuite.com is CDN-fronted. Directs users to 2FA, token-based auth and OAuth 2.0 instead, or to a DNS lookup on outboundips.netsuite.com. NetSuite Connector IS published, see the netsuite-connector service.
Source: https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_N251955.html. That page is where this entry comes from, so you can check it rather than take our word for it.
what this vendor does publish
The same company publishes the addresses the Connector reaches your systems from for NetSuite Connector, which is in the catalog and can be pinned. The gap above applies to this product, not to everything they run.
what to do instead
Pick the control the vendor actually supports, and keep it scoped to the one workload that needs it:
- Verify the message, not the sender. Where a vendor signs its webhooks, checking the signature is stronger than an address check would have been, and it survives their infrastructure changing.
- Allow the hostname. Where a vendor publishes a stable domain, that needs something which resolves names: a proxy, a DNS firewall, or a network firewall rule group. A security group cannot do it.
- Contain the blast radius. Give that workload its own security group so the broad rule lives there and nothing else in the account inherits it. Coverage has a worked example.
the rest of your stack
One unpinnable dependency does not stop you pinning the others. The catalog covers the vendors that do publish official ranges, and the vendor report scores how well each one publishes.