feat(netsuite): add best practices SAST governance rules

[joshOrigami]

Title: feat(javascript): Add NetSuite SAST governance and best practices ruleset

Description:

This PR introduces the first foundational SAST ruleset for Oracle NetSuite (SuiteScript) to the Semgrep registry.

NetSuite runs on a proprietary JavaScript API (SuiteScript 2.x) executed via a GraalVM backend. Because it is a multi-tenant cloud ERP, it enforces strict "Governance Limits" (usage units) on database operations. Standard JavaScript linting cannot catch these platform-specific governance traps, which often lead to fatal SSS_USAGE_LIMIT_EXCEEDED errors in production.

With the rapid adoption of AI-generated code (Copilot, Claude), this problem is escalating. AI models frequently write naive "Happy Path" JavaScript that works syntactically but violently violates NetSuite's database governance. This ruleset acts as a gatekeeper to prevent architectural anti-patterns from reaching production.

Rules Included in this PR:

1. netsuite-no-record-load-save-in-loop:
   • The Risk: Loading or saving a NetSuite record inside a for/while/for each loop creates an $O(n^2)$ performance bottleneck and rapidly burns through script governance units.
   • The Fix: Forces developers to rethink the architecture and use bulk-fetch mechanisms like N/search or N/query outside the loop.
2. netsuite-unhandled-aftersubmit-try-catch:
   • The Risk: NetSuite User Event afterSubmit triggers execute after the 'database' commit but before the user's UI resolves. An unhandled exception here can cause data inconsistency or block the user from saving the record entirely.
   • The Fix: Enforces a root-level try/catch block for mission-critical entry points.
3. netsuite-no-console-log:
   • The Risk: Using standard browser console.log in backend SuiteScript is an audit and execution risk.
   • The Fix: Enforces the use of NetSuite's native telemetry module (N/log).

Testing:

• Added comprehensive _test.js files covering ruleid hits and ok passes for all patterns.
• Passed local semgrep --validate checks.

About the Author:
My name is Joshua Meiri, and I specialize in AI-Native NetSuite Engineering. I am the creator of the ABCD (Always Be Continuously Deliberate) methodology, which transitions NetSuite teams from legacy, UI-based scripting into modern, testable, MVC-driven DevOps lifecycles. I have over 20 years of experience in CRM and ERP systems and the creator of origami lens of NetSuite metadata exploration.

I built these rules because the ecosystem currently lacks a standardized, automated defense against AI-generated hallucinations and legacy messy code. By contributing this to the official registry, I hope to establish a true "financial primitive" of platform-wide safety for NetSuite developers globally.

More rules to come!

[CLAassistant]

All committers have signed the CLA.

[stephen-lemp]

Some review from a fellow SuiteScript developer. Thanks for the contribution here @joshOrigami!

[stephen-lemp]

The save will still occur, though the error will be raised to the user without a try-catch. I'm not sure that failing silently is a best practice here. NetSuite already wraps afterSubmit and like functions with a try-catch to ensure it doesn't crash the server, and they properly raise the error to the user.

[joshOrigami]

Great catch, Stephen. You’re spot on regarding the post-commit nature of afterSubmit—the save is done, and NetSuite’s native handler does prevent a total server-hang.

My intent with this rule isn't to encourage 'silent failures' (swallowing errors), but to enforce deliberate handling. I see too many scripts that crash and leave external systems (integrations, custom records) in an inconsistent state because the dev relied on the generic NS error page instead of a structured catch that logs proper context or triggers a fallback.

I’ll refine the rule message to emphasize 'Structured Error Handling' rather than just 'Avoid Crashing.' Appreciate the sharp eye!

[stephen-lemp]

The no-console-log rule needs to be scoped to server-side scripts only.
It should be acceptable in client scripts.

[joshOrigami]

@stephen-lemp on this one I disagree, as releasing (client side) code into Production where you are potentially logging "stuff" to console is an Anti-Pattern. Agree this should be a warning.

[stephen-lemp]

This will not always cause SSS_USAGE_LIMIT_EXCEEDED, particularly if user includes a limit. For example, in a Suitelet the user might check number of records to load/save. If the Suitelet can cover it with 1000 governance units, it would process, otherwise it would offload to Map/Reduce. This is a valid pattern.

[joshOrigami]

Spot on, Stephen. The 'Suitelet-to-M/R offload' is a classic high-perf pattern. I’m updating the message to acknowledge that usage-limit checks and offloading are the valid exceptions here.

My goal with the initial ruleset is to catch the 90% of cases where someone is just 'loop-loading' without a safety net. I’ll refine the severity and the wording so it reads more as a performance audit than a hard block. Thanks for keeping the edge cases in mind!

• will add '- pattern-not-inside: ' for map/reduce usage.

[stephen-lemp]

I'd recommend considering this a WARNING/Medium severity

[joshOrigami]

agree, will change.