All data that is flows into Foundry is type checked by the application developer. If data is not pre-configured then it is imported as a non-executable string type. It is the responsibility of the developer to configure the appropriate data types.
At no time is any incoming data used as an execution parameter, rather data is acted upon by internal functions (Lambda) functions and stored as non-executable string in a no sql database (Dynamodb).
Foundry at its core is based upon message flow over AWS IoT core. In order for external devices/system to communicate with Foundry it will require a unique certificate.
AWS IoT can use AWS IoT-generated certificates or certificates signed by a CA certificate for device authentication. Certificates generated by AWS IoT are long-lived (but will expire at 2049-12-31T23:59:59Z, that is at midnight GMT on December 31, 2049.) The expiry date and time for certificates signed by a CA certificate are set when the certificate is created.
Server certificates allow your devices to verify that they're communicating with AWS IoT and not another server impersonating AWS IoT. Service certificates need to be copied onto your device and referenced when connecting to AWS IoT. For more information, see the AWS IoT Device SDKs. AWS IoT server certificates are signed by one of the following CA certificates:
VeriSign Endpoints (legacy)
Amazon Trust Services Endpoints (preferred)
We recommend that all customers create an Amazon Trust Services (ATS) endpoint and load these CA certificates onto their devices to avoid any issues with the widespread distrust by browsers of Symantec CAs (including VeriSign) that occurred in October 2018. For backward-compatibility reasons, we still support customers using these endpoints. Customers can create an ATS endpoint by calling the describe-endpoint API with the iot:Data-ATS endpointType. Devices operating on ATS endpoints are fully interoperable with devices operating on Symantec endpoints in the same account and do not require any reregistration.