Application variables are limited in range. A byte, for instance, can only represent 256 different values. If "7" is added to "250," then this will result in a byte value of "1." Attackers might abuse these unexpected results. If an application accepts serialized objects (e.g., ASN.1), great care must be taken when the objects are deserialized to prevent attackers from executing code unauthorized. Sometimes developers build backdoors into an application in order to facilitate debugging. Attackers can also make use of them, which is why this kind of functionality should not be present in a production environment. The security of an application that loads code or uses functionality from a source that is not under the full control of the developer, relies on the good intentions and the security of the party who provides the code. The invoked scripts often run with the same level of access as the code of the application itself. When applications evolve, functionality is sometimes re-implemented. The obsolete implementation should be removed from the application to prevent abuse. Applications and apps can interface with external systems. If the communication is protected with SSL/TLS (Transport Layer Security) then it is required that both the server and client check whether the used certificates are valid. They should not be expired or revoked and signed by a reputable certificate authority (this also include a company's own CA). Advanced application components can require careful configuration to be deployed securely. In application components, as in all other software, security vulnerabilities are discovered continuously. As soon as such vulnerabilities are publicly released, or get otherwise publicly known, they may be exploited by attackers. Therefore it is essential to patch software as soon as possible with a secure software update mechanism (refer to the discussion on secure boot). To resolve security vulnerabilities, all vendors including third parties and communities actively maintain software. This is only 