SC-18 Mobile Code asks for two things. Define acceptable and unacceptable mobile code and mobile code technologies. And authorize, monitor and control the use of mobile code within the system.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from, so check which parts your customer or auditor actually expects.
The guidance defines mobile code as any program, application or content that can be transmitted across a network, for example in an email, a document or a website, and executed on a remote system. It lists Java applets, JavaScript, HTML5, WebGL and VBScript. Decisions rest on the potential for damage if the code is used maliciously, and they cover both servers and workstations, including notebook computers and smart phones. Policy should address preventing the development, acquisition and introduction of unacceptable mobile code, including requiring mobile code to be digitally signed by a trusted source.
What it means in practice
If your staff open web pages and documents with macros, they run mobile code every day. If your product ships JavaScript to customers, you are also a mobile code supplier. SC-18 has a buyer side and a builder side.
On the buyer side, write down which technologies are allowed where. Browser scripting is allowed, macros are allowed only from signed sources, and legacy plugins are banned. Then enforce it through browser and office settings, endpoint tools and email filtering.
On the builder side, think about the third party scripts you embed. Tag managers, analytics snippets and package dependencies are mobile code you introduce into your customers' browsers. SC-18.2, Acquisition, Development, and Use, speaks to this.
The five enhancements: SC-18.1 identify unacceptable code and take corrective action, SC-18.2 acquisition, development and use, SC-18.3 prevent downloading and execution, SC-18.4 prevent automatic execution, SC-18.5 allow execution only in confined environments.
Evidence to collect
- A mobile code policy listing acceptable and unacceptable technologies and where each applies.
- Endpoint and browser configuration, such as macro policy, script restrictions or extension allow lists.
- Email and web gateway rules for blocking risky attachments and downloads.
- A procedure for approving new third party scripts on your own sites, with a record of approvals.
- Content security policy settings for your public web properties.
- A dependency scan result for client side packages, showing known vulnerable versions are tracked.
- Monitoring and alerts for blocked execution attempts.
Common gaps
No written definition, only habit. Office macros allowed from the internet by default. Browser extensions installed without review. Analytics and chat widgets added by marketing without security sign off, and no content security policy to limit what they can load. Client side dependencies never scanned because the scanner only looked at the server. A package update that quietly changes what code ships to users.
How to implement it
Write the policy in plain language. A table with technology, allowed or not, conditions and owner is enough.
Enforce it on endpoints. Block macros from the internet, restrict extensions to an approved list, and prevent automatic execution of downloaded content where practical. Use isolation for risky browsing if you have it, which maps to SC-18.5.
Then manage what you send out. Keep an inventory of every third party script and package that reaches customers' browsers. Add a content security policy that lists permitted sources, and require review for additions. Pin and verify versions of client side packages.
Scan the packages. The free in browser scan at https://gold.safeguard.sh/scan lets you check a dependency manifest for known vulnerable packages without sending your repository anywhere. A software bill of materials for your front end gives you the inventory to compare against.
Finally, monitor. Collect blocked execution events and content security policy violation reports and review them regularly. Treat a new, unexplained source as an incident until proven otherwise.
Consider a realistic case for the builder side. A marketing team adds a chat widget and a heatmap tool to the company website through a tag manager. Neither went through security review, and both load further scripts from other domains. If one of those vendors is compromised, the attacker can run code in every visitor's browser, including visitors logged in to your product. A content security policy that lists permitted script sources would have blocked the unknown loads, and an approval step for new scripts would have prompted a question about necessity and ownership.
On the buyer side, think about documents. A finance employee receives a spreadsheet with a macro. If your policy blocks macros from the internet by default and allows signed macros from approved publishers, the risky file simply does not run. That is the kind of concrete setting you can screenshot as evidence.
Keep the policy short enough that people read it, and tie each rule to a setting you can show. A statement with no matching configuration will not survive the first follow up question.
Finally, remember that mobile code arrives through dependencies too. A package update can add a new postinstall script or change what ships to browsers. Version pinning, lockfiles and routine scanning make those changes visible.
Try it yourself
Knowing which packages ship in your front end starts with an inventory. This demo shows how a software bill of materials is generated.
Click through it at your own pace, or open it full screen.
Quick check
Is JavaScript on my own website covered?
Yes. The guidance lists JavaScript and HTML5 as mobile code technologies, and your site delivers it to others. Document what you ship and what third party code you load.
What does digitally signed mobile code give me?
Evidence that it came from a trusted source and was not altered. The guidance suggests requiring it in policy.
