cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Newcomer II

Tomorrows apps, methods of yesterday

I guess, it will not be a total surprise for you, that the GDPR will hit in on May 25th in just a few days? But are we ready to meet the enhanced requirements for the Article 25 - “by default & by design”? Have we adjusted the systems development lifecycle to comply with the GDPR, or are we just taking the existing methods into the new era of legislation, without the proper and necessary changes being applied? If so, problems may arise.

 

https://www.linkedin.com/pulse/tomorrows-apps-methods-yesterday-michael-christensen/

 

Compliance and InfoSec Consultant
1 Reply
Community Champion

Re: Tomorrows apps, methods of yesterday

Fair question and I suspect that the answer is a resounding "No".

 

Wide acceptance of agile development methodologies decoupled from education in security subject matter resulted in the Minimum Viable Product mentality in companies that are rushing features and capabilities to the market, risk be damned.

 

Inevitably, numbers of vulnerabilities and resulting compromises are on the rise. Very few entities are capable of defining what the "secure by design" actually means in relation to their product(s) or services, never mind actually implementing and maintaining it.

 

When we consider what resources actually necessary for the implementation of sound GRC and corresponding controls, we will inevitably arrive at a certain baseline in a number of positions and people required for it. This could be attained by the companies of certain size and deep pockets.

 

To your question and to my point there is a post here by leroux: 41% of cyber-security apps contain high-risk open source vulnerabilities

 

that describes even more troubling issue. The very tools we are supposed to trust introducing additional issues.