Method and system for controlling software risks for software development

A computer-implemented method of controlling a potentially unacceptable software component intended for a repository environment which includes a software repository, comprising:

• providing, in a policy storage, a pre-defined repository policy which defines risks that determine software components deemed acceptable and/or unacceptable for adding to the software repository, the pre-defined repository policy defines, for each of the risks, an action to take for the risk, wherein the actions to take for the risk are selected from at least a pass action and a does-not-pass action, wherein the actions are pre-defined programmatic steps,
• wherein the does-not-pass action, which pre-defines how to dispose of the software components which do not pass the repository policy, is configured to be pre-selected one or more of a plurality of pre-determined, selectively-combinable does-not-pass-actions,
• wherein the does-not-pass action is further configured to specify pre-selected different combinations of the does-not-pass actions which are pre-selected per each different stage of enforcement, wherein the risks are further evaluated based on the stage of enforcement;
• determining, by a processor, responsive to an activity that includes a plurality of software components, wherein each of the software components is a canonical version, for each of the software components, whether the canonical version of the software component is new to the software repository;
• when the software component is determined to not be new to the software repository:
• passing, by the processor, the software component through;
• when the software component is determined to be new to the software repository, then prior to adding the software component to the software repository:
• determining, by the processor, from a risk match unit, risks which match the software component, wherein the risks which match the software component are determined based on a lookup key which is unique to the canonical version of the software component;
• evaluating, by the processor, the risks which were determined to match the software component, to determine the actions, as defined in the pre-defined repository policy, to take for the risks determined to match the software component, wherein the action to take is specific to a type of the risk and defines how to dispose of the software component, wherein the does-not-pass action, which pre-defines how to dispose of the software component which does not pass the repository policy, is configured to be a pre-selected plurality of pre-determined, selectively-combinable does-not-pass-actions;
• when the risk of the software component is evaluated to pass the pre-defined repository policy, following, by the processor, the pass action, defined in the pre-defined repository policy, for the determined action, wherein the pass action includes to add the software component to the software repository;
• when the risk of the software component is evaluated to not pass the pre-defined repository policy, following, by the processor, the pre-selected plurality of one or more does-not-pass-actions of the does-not-pass action, defined in the pre-defined repository policy, for the determined action.

A computer-implemented method of controlling a potentially unacceptable software component intended for a repository environment which includes a software repository, comprising:

• providing, in a policy storage, a pre-defined repository policy associated with the repository environment, the pre-defined repository policy defines risks and, for each of the risks, an action to take for the risk, wherein the actions to take for the risk are selected from at least a pass action and a does-not-pass action, wherein the actions are pre-defined programmatic steps;
• determining, by a processor, responsive to receiving a request for a software component, whether the software component which is requested is new to the software repository;
• when the software component is determined to not be new to the software repository:
• passing, by the processor, the software component through;
• when the software component is determined to be new to the software repository, then prior to adding the software component to the software repository:
• determining, by the processor, from a risk match unit, risks which match the software component;
• evaluating, by the processor, the risks which were determined to match the software component, to determine the actions, as defined in the pre-defined repository policy, to take for the risks determined to match the software component;
• following, by the processor, the pass action, defined in the pre-defined repository policy, for components that are determined to pass, wherein the pass action includes to add the software component to the software repository, when the risk of the software component is evaluated to pass the pre-defined repository policy;
• following, by the processor, the does-not-pass action, defined in the pre-defined repository policy, for components that are determined to not pass as a potentially unacceptable software component, when the risk of the software component is evaluated to not pass the pre-defined repository policy,
• wherein the pre-defined repository policy further comprises a pre-defined action to take for a partially matching software component,
• further comprising, when the software component is determined to be new to the software repository,
• when it is determined that the software component does not match any of the components that is known to the risk match unit,
• recursively performing, by the processor, a deep inspection of internal software components at a next layer internal to the software component until the internal software components are determined which match a known component which is known to the risk match unit;
• performing the step of determining the risks, for the internal software components which are matched to known software components;
• performing the step of evaluating the risks, for the risks of the internal software components which are matched to known software components;
• performing the step of following the action defined in the pre-defined repository policy, for the risks of the internal components which are matched to known components, in combination with following the pre-defined action to take for the partially matching software component.

A computer-implemented method of controlling a potentially unacceptable software component intended for a repository environment which includes a software repository, comprising:

• providing, in a policy storage, a pre-defined application policy associated with both the repository environment and an application, the pre-defined application policy is different from a policy associated with the repository and the pre-defined application policy can be different from policies associated with other applications, the pre-defined application policy defines risks and, for each of the risks, an action to take for the risk, wherein the actions to take for the risk are selected from at least a pass action and a does-not-pass action, wherein the actions are pre-defined programmatic steps;
• determining, by a processor, responsive to a commit asset action or build action for the application that includes software components, for each of the software components, whether the software component is new to the application;
• when the software component is determined to not be new to the application:
• passing, by the processor, the software component through;
• when the software component is determined to be new to the application:
• determining, by the processor, from a risk match unit, risks which match the software component;
• evaluating, by the processor, the risks which were determined to match the software component, to determine the actions, as defined in the pre-defined application policy, to take for the risks determined to match the software component;
• following, by the processor, the pass action, defined in the pre-defined application policy, for components that are determined to pass, wherein the pass action includes to add the software component to the software repository, when the risk of the software component is evaluated to pass the pre-defined application policy;
• following, by the processor, the does-not-pass action, defined in the pre-defined application policy, for components that are determined to not pass as a potentially unacceptable software component, when the risk of the software component is evaluated to not pass the pre-defined application policy,
• wherein the pre-defined application policy further comprises a pre-defined action to take for a partially matching software component,
• further comprising, when the software component is determined to be new to the application,
• when it is determined that the software component does not match any of the components that is known to the risk match unit,
• recursively performing, by the processor, a deep inspection of internal software components at a next layer internal to the software component until the internal software components are determined which match a known component which is known to the risk match unit;
• performing the step of determining the risks, for the internal software components which are matched to known software components;
• performing the step of evaluating the risks, for the risks of the internal software components which are matched to known software components;
• performing the step of following the action defined in the pre-defined application policy, for the risks of the internal components which are matched to known components, in combination with following the pre-defined action to take for the partially matching software component.