Re: Will the Open Group consider incorporating software security features in its software technical standards given the fact that these days lots of software are getting hacked?

[David A. Wheeler via austin-group-l at The Open Group]

> On Jan 31, 2026, at 2:37 AM, Amit via austin-group-l at The Open Group 
> <austin-group-l@opengroup.org> wrote:
> 
> Hi,
> 
> Will the Open Group consider incorporating software security features
> in its software technical standards given the fact that these days
> lots of software are getting hacked?
> 
> """"Basically, I am proposing that the inputs of all functions should
> be validated.""""

If there are appropriate mechanisms to improve software security at this level 
that would
be of great interest to me. However, you'll need to find
specific examples that *this* group addresses, and show that the given
inputs are *NEVER* valid (or that the added more-complex control is worth 
adding).

> About limits on the inputs: Let's say that there is a sorting function
> that sorts an integer array, and it takes the number of array elements
> as an input. In this case, you can limit the maximum number of
> elements to around 10% of the RAM size and the total size of the
> array to around 25% of the RAM size.

I don't agree with this example at all.
*YOU* might not have large datasets, but many other users *DO* have large 
datasets.
Why is everyone forbidden to use 75-90% of our RAM when sorting?
This would destroy availability, which is *also* part of the definition of 
security.

> The most important part of creating secure software is to validate all the
> inputs of all the functions.

It's certainly important to validate inputs for security! But that requires 
that you
know what the valid inputs *are*.

I suggest looking for strong specific proposals relevant to this group. E.g.:

1. Cases where it's obvious that certain inputs should *never*.be allowed,
    especially if it's not hard to detect during processing.
2. Cases where inputs are currently undefined but should be clearly defined
    or defined to have limited options to prevent undefined behavior.
3. Mechanisms that would make it easier, more generally, to perform
    application-specific validation. Improvements to regex come to mind here.

--- David A. Wheeler