METHOD AND SYSTEM FOR CONTROLLING SOFTWARE RISKS FOR SOFTWARE DEVELOPMENT

• US 20170147338A1
• Filed: 11/25/2015
• Published: 05/25/2017
• Est. Priority Date: 11/25/2015
• Status: Active Grant

• Current Assignee: Sonatype
• Original Assignee: Sonatype
• Inventors: JACKSON, Wayne, HANSEN, Michael, FOX, Brian, WHITEHOUSE, Jaime, DILLON, Jason
• Granted Patent: US 10,540,176 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 11/008 Reliability or availability analysis
• CPC Class Codes: G06F 11/36 Preventing errors by testing or debugging software
• CPC Class Codes: G06F 21/105 Arrangements for software license management or administration, e.g. for managing licenses at corporate level
• CPC Class Codes: G06F 21/577 Assessing vulnerabilities and evaluating computer system security
• CPC Class Codes: G06F 2221/033 Test or assess software
• CPC Class Codes: G06F 8/36 Software reuse
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: G06F 8/77 Software metrics

Abstract

A computer system, method, or computer-readable medium controls a potentially unacceptable software component intended for a software repository. A pre-defined application or repository policy associated with the repository or application pre-defines risks and, for each of the risks, an action to take for the risk. The action can be a pass action or a does-not-pass action, which are pre-defined programmatic steps also defined in the policy. When the component is not new to the repository or the application, the component is passed through for the usual handling. When the component is new, risks are determined that match the software component; for risks which match, the actions are taken as defined in the pre-defined policy. The pass action can include adding the software component to the software repository. The does-not-pass action is followed for a component that does not pass as a potentially unacceptable software component.

Claims

1. 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;

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.

2. The method of claim 1,

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.

3. The method of claim 1, further comprising a quarantine storage which is quarantined from user access, and a log of components in the quarantine storage,

further comprising, by the processor, isolating the software component, which is determined to be the potentially unacceptable software component, by being stored into quarantine storage instead of being stored in the software repository;

and storing a fact that the software component is quarantined; and

further determining, by the processor, responsive to receiving the request for the software component, whether the software component which is requested is in the quarantine storage, and providing a quarantine notification that the software component is determined to be quarantined and not in the software repository.

4. The method of claim 3, further comprising, when the software component is determined to be quarantined,

determining, by the processor, a different version of the quarantined component, wherein the different version passes the pre-defined repository policy,

the quarantine notification indicates the different version of the quarantined component that passes the pre-defined repository policy.

5. The method of claim 3, further comprising, for the quarantined component, by the processor, guiding a user through determining whether the quarantined component should be accepted into the software repository as waived, and then moving the quarantined component which is waived from the quarantine into the software repository.

6. The method of claim 1, wherein the determination of the risks includes

preparing, by the processor, a risks lookup key based on metadata of the software component;

and

retrieving, by the processor, based on the risks lookup key from the software component, information indicating the risks of the software component.

7. The method of claim 1, wherein

the risks, defined in the pre-defined repository policy for software components, include licenses to which the software component is subject, and security vulnerabilities of the software component,

the determination of the risks includes

preparing, by the processor, based on metadata from the software component, a licenses-lookup key and a security-vulnerabilities-lookup key, which are both unique to the software component;

retrieving, by the processor, from a licenses-lookup information provider, based on the licenses-lookup key for the software component, information indicating the licenses of the software component; and

retrieving, by the processor, from a security vulnerabilities information provider, based on the security-vulnerabilities-lookup key for the software component, information indicating the security vulnerabilities of the software component.

8. The method of claim 1, wherein the action to take when the software component is determined to be new to the software repository and the risks of the software component are all evaluated to pass the pre-defined repository policy with no errors, include one or more of

logging, by the processor, the software component which is being added to the software repository,

notifying, by the processor, via e-mail, of the new component.

9. A computer, comprising:

an i/o interface operable to communicate with a software repository; and

a processor cooperatively operable with the i/o interface, and configured to perform the method of claim 1.

10. A non-transitory computer readable medium comprising executable instructions for performing the method of claim 1.

11. 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 which is requested 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 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 application policy.

12. The method of claim 11,

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.

13. The method of claim 11, further comprising a quarantine storage which is quarantined from user access, and a log of components in the quarantine storage,

further comprising, by the processor, isolating the software component, which is determined to be the potentially unacceptable software component, by being stored into quarantine storage instead of being stored in the software repository;

and storing a fact that the software component is quarantined; and

further determining, by the processor, responsive to receiving the request for the software component, whether the software component which is requested is in the quarantine storage, and providing a quarantine notification that the software component is determined to be quarantined and not in the software repository.

14. The method of claim 11, further comprising, when the software component is determined to be the potentially unacceptable software component according to the application policy,

determining, by the processor, a different version of the potentially unacceptable software component, wherein the different version passes the pre-defined application policy, and

providing a notification which indicates that the software component is not acceptable and which indicates the different version of the potentially unacceptable software component that passes the pre-defined application policy.

15. The method of claim 14, further comprising, for the potentially unacceptable software component, by the processor, guiding a user through determining whether the potentially unacceptable software component should be accepted into the build or commit as waived, and then moving the potentially unacceptable software component which is waived into the software repository and using the potentially unacceptable software component in the build or commit.

16. The method of claim 11, wherein the determination of the risks includes

preparing, by the processor, a risks lookup key based on metadata of the software component;

and

retrieving, by the processor, based on the risks lookup key from the software component, information indicating the risks of the software component.

17. The method of claim 11, wherein

the risks, defined in the pre-defined application policy for software components, include licenses to which the software component is subject, and security vulnerabilities of the software component,

the determination of the risks includes

preparing, by the processor, based on metadata from the software component, a licenses-lookup key and a security-vulnerabilities-lookup key, which are both unique to the software component;

retrieving, by the processor, from a licenses-lookup information provider, based on the licenses-lookup key for the software component, information indicating the licenses of the software component; and

retrieving, by the processor, from a security vulnerabilities information provider, based on the security-vulnerabilities-lookup key for the software component, information indicating the security vulnerabilities of the software component.

18. The method of claim 11, wherein the action to take when the software component is determined to be new to the application and the risks of the software component are all evaluated to pass the pre-defined application policy with no errors, include one or more of

logging, by the processor, the software component which is being added to the software repository,

notifying, by the processor, via e-mail, of the new component.

19. A computer, comprising:

an i/o interface operable to communicate with a software repository; and

a processor cooperatively operable with the i/o interface, and configured to perform the method of claim 11.

20. A non-transitory computer readable medium comprising executable instructions for performing the method of claim 11.