Re: Draft criteria for passing+1 and pasing+2 - comments?


liujin
 

David,

 

It is noticed code review suggestion and rules had set to “Probably not”,  and it may not be a right choice.

 

The OSASP Top 10 secure issues are too rough to operate, and there are hundreds rules in  CERT suggestion. Both are hard to be used directly.

 

Even today, buffer overflow, integer overflow, and improper validation of array index is still the most common C language code security issues.For small software, to do code review is very easy to operate, and it is the best way to find out most of the ootential code secure fault in small software, e.g., the software less than 100 thousand lines of code. Code view convenient and cheap.For large software, code review has almost become the industry standard. For example, Google and Microsoft have established a clear code view system. This is because the code view is always more accurate and can make up for the lack of static code checking tools.

 

The code review suggestions as following:

1.The direct data or the indirect data from the untrusted sources which is used as the array index MUST be ensured within a legal range.

2.The direct data or the indirect data from the untrusted sources which is used as the buffer length for read/write MUST be ensured within a legal range.

3.The direct data or the indirect data from the untrusted sources which is used as the loop ending condiction MUST be avoided infinite loop or other logic mistake.

4.When copying from a string that is not a trusted source, it MUST ensure that there is enough space to hold the data and the end.

5.The integer values from untrusted sources MUST be avoided the integer overflow or wraparound.

6.Appropriate size limits SHOULD be used to allocate memory from an unreliable source, and MUST check the return value of the allocate function. 

 

The above 6 rules are very simple and very detail, but they can help us to avoid the most dangerous codes’ mistakes. It may be the beginning that helps us improve the efficiency of the code review by specifying rules. We hope that through the contribution of the people, the extraction of limited code view rules can reduce most of our security coding problems.

 

Best Regards

 

--- Jin Liu

 

发件人: cii-badges-bounces@... [mailto:cii-badges-bounces@...] 代表 Wheeler, David A
发送时间: 2017221 10:44
收件人: cii-badges@...
主题: [CII-badges] Draft criteria for passing+1 and pasing+2 - comments?

 

We have an updated draft set of criteria for “passing+1” and “passing+2”:

  https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md

 

These are *not* the final product – but I’d really like to hear comments about them.

 

I really want to make it *possible* for small projects to get higher-level badges, but clearly *some* activities that reduce risk for users *do* require more people (e.g., for multi-person review, bus factor, etc.).  The current draft attempts to make passing+1 possible for small projects, while passing+2 includes criteria that help a project but are not practical for small projects.  Well, that was the idea anyway.

 

--- David A. Wheeler

 

Join CII-badges@lists.coreinfrastructure.org to automatically receive all group messages.