Abstract: An improved static program analysis procedure is provided by formulating a set of seeding configurations, and selecting a subset of queries posed by the static program analysis procedure. In response to one or more queries of the subset of queries being answered positively under at least one configuration of the set of seeding configurations, the one or more queries are determined to be valid queries. Each query of the valid queries is evaluated under each configuration of the set of seeding configurations to determine an accuracy score for each seeding configuration. A seeding configuration having a highest accuracy score is selected as a tool configuration to be used with the static program analysis procedure.

Abstract: An improved static program analysis procedure is provided by formulating a set of seeding configurations, and selecting a subset of queries posed by the static program analysis procedure. In response to one or more queries of the subset of queries being answered positively under at least one configuration of the set of seeding configurations, the one or more queries are determined to be valid queries. Each query of the valid queries is evaluated under each configuration of the set of seeding configurations to determine an accuracy score for each seeding configuration. A seeding configuration having a highest accuracy score is selected as a tool configuration to be used with the static program analysis procedure.

Abstract: A method of static source code analysis is provided. A forward search of source code is performed from each of a plurality of source nodes. A backward search of source code is performed from each of a plurality of sink nodes, wherein the forward search and the backward search are performed in parallel simultaneously. The progress of the forward search and the backward search are monitored to determine if the searches intersect at a common node. A vulnerability alert is generated when the monitoring determines that a forward search and a backward search reach a common node.

Abstract: A method of static source code analysis is provided. A forward search of source code is performed from each of a plurality of source nodes. A backward search of source code is performed from each of a plurality of sink nodes, wherein the forward search and the backward search are performed in parallel simultaneously. The progress of the forward search and the backward search are monitored to determine if the searches intersect at a common node. A vulnerability alert is generated when the monitoring determines that a forward search and a backward search reach a common node.

Abstract: An application includes: a programming model including a service provider, first components, second components, and sinks communicating via messages. Each of the second components is assigned a unique capability. A given one of the first components routes a message from the given first component to second component(s) and then to a sink. Each of the second component(s) sends the message to the service provider. The service provider creates a token corresponding at least to a received message and a unique capability assigned to an associated one of the second component(s) and sends the token to the associated one of the second component(s). The selected sink receives the message and a token corresponding to each of the second component(s), verifies each received token, and either accepts the message if each of the received tokens is verified or ignores the message if at least one of the received tokens is not verified.

Abstract: An application includes: a programming model including a service provider, first components, second components, and sinks communicating via messages. Each of the second components is assigned a unique capability. A given one of the first components routes a message from the given first component to second component(s) and then to a sink. Each of the second component(s) sends the message to the service provider. The service provider creates a token corresponding at least to a received message and a unique capability assigned to an associated one of the second component(s) and sends the token to the associated one of the second component(s). The selected sink receives the message and a token corresponding to each of the second component(s), verifies each received token, and either accepts the message if each of the received tokens is verified or ignores the message if at least one of the received tokens is not verified.

Abstract: An application includes: a programming model including a service provider, first components, second components, and sinks communicating via messages. Each of the second components is assigned a unique capability. A given one of the first components routes a message from the given first component to second component(s) and then to a sink. Each of the second component(s) sends the message to the service provider. The service provider creates a token corresponding at least to a received message and a unique capability assigned to an associated one of the second component(s) and sends the token to the associated one of the second component(s). The selected sink receives the message and a token corresponding to each of the second component(s), verifies each received token, and either accepts the message if each of the received tokens is verified or ignores the message if at least one of the received tokens is not verified.

Abstract: An application includes: a programming model including a service provider, first components, second components, and sinks communicating via messages. Each of the second components is assigned a unique capability. A given one of the first components routes a message from the given first component to second component(s) and then to a sink. Each of the second component(s) sends the message to the service provider. The service provider creates a token corresponding at least to a received message and a unique capability assigned to an associated one of the second component(s) and sends the token to the associated one of the second component(s). The selected sink receives the message and a token corresponding to each of the second component(s), verifies each received token, and either accepts the message if each of the received tokens is verified or ignores the message if at least one of the received tokens is not verified.