In the digital world, every application we build is a potential target. Yet, far too many development teams still treat security as an afterthought—a quick penetration test tacked onto the end of a project before launch. This reactive approach is inefficient, expensive, and frankly, dangerous.

The solution is the Secure Software Development Lifecycle (SSDLC), and it’s built on one simple, powerful idea: Shift Left.

The Problem with the Waterfall Model

Recall the traditional, sequential Waterfall Model. Security often shows up late, usually in the testing or validation phase.

When a critical design flaw is found late in the cycle, what happens? Development stalls, costs skyrocket, and the pressure to launch often leads to weak patches instead of true fixes. This is the definition of “bolting security on.”

The SSDLC and the “Shift Left” Philosophy

The SSDLC replaces the rigid, sequential approach with an iterative, cyclical one, much like the Agile methodology. In this model, security checks are performed continuously, shifting the responsibility for security from a single QA team member at the end of the project to every team member in every phase.

Security is a Feature, Not a Phase

In the SSDLC, security activities are integrated directly into your existing development sprints:

• Planning: Security requirements are defined alongside functional requirements (e.g., “All user data must be encrypted in transit and at rest”).
• Design: Threat Modeling is conducted to identify and mitigate design flaws before a single line of code is written.
• Implementation: Developers use Secure Coding Practices (Lecture 5!), such as input validation and parameterized queries.
• Testing: Automated tools (SAST, DAST) run continuously in the CI/CD pipeline to flag common vulnerabilities instantly.

Threat Modeling: The SSDLC Superpower

The most critical step in the “Shift Left” approach is Threat Modeling, performed during the Design phase. It forces you to think like an attacker by analyzing how data moves through your system.

How it Works (Using Data Flow Diagrams)

A common technique is the Data Flow Diagram (DFD). By mapping out where sensitive data is stored, processed, and transmitted, you can systematically analyze the risks.

For instance, when designing a simple checkout system, a DFD (like the one we drew) helps identify every point where a threat categorized under STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) could occur.

• Risk Focus: When analyzing the flow of customer PII (personally identifiable information) into the database, you immediately ask: “How could an attacker achieve Information Disclosure here?” This leads you to enforce encryption and strong access controls.

The Business Case for Secure Development

Integrating the SSDLC isn’t just “doing the right thing”; it’s a sound business decision:

1. Reduced Costs: Fixing a bug in the requirements or design phase is up to 100 times cheaper than fixing it in production.
2. Faster Delivery: By finding and fixing vulnerabilities early and automatically, you prevent major security incidents that can halt deployments for weeks.
3. Customer Trust & Compliance: Strong security practices ensure you meet regulatory requirements (like GDPR or HIPAA) and maintain the trust of your users.

The takeaway is clear: Make security an integrated part of your development culture. Stop bolting it on, and start building it in.

Following presentation highlights the need and structure of an SRS.

Photo by Caitlinator

Photo by Predi

SSBSE Challenge Track

The papers must be at most 6 pages long in PDF format and should conform at time of submission to the SSBSE/Springer LNCS format and submission guidelines. They must not have been previously published, or be in consideration for, any journal, book, or other conference.

Photo by Loretín

having all of such tools and techniques, a very important question that should appear in our consciousness is that what should we develop with these tools. In a short life that we have, we have an enormous amount of work that needs to be done. Not all of this work is equally valuable. We should learn how to prioritize the projects that we can do based on their impact and the value they would add to our lives in one way or the other.

This aspect has kept me thinking for the past some time. I see people who are subscribing to doing typical run-of-the-mill types of projects such as to develop typical web applications. Such applications are so widespread now.

I met another group who wanted to develop a database management system. I personally do not have anything against it. As a matter of fact, developing a full-fledged database management system is a very challenging goal to undertake. There are a lot of aspects to it. There is file IO. There is the query parser. Add to this the desire to have a graphical user interface for such a system, the requirements simply seem to become difficult to manage.

Such systems are very valuable as well. Database management systems play a great role in almost every feat today.

But my argument against developing such a system is that database management systems are quite mature nowadays. The field is also quite saturated, well understood and well developed. There are so many open source versions available that you can download any of them within less than a minute and start using it.

I argue, then, that why shouldn’t we invest our energies in developing systems that are relatively less explored and can have a huge impact on the society. I personally like to advocate about unmanned aerial vehicles, to this end. Similarly, developing newer and more efficient renewable energy systems can have a huge impact on the way we consume energy. There are other such systems and problems that can be thought about as well. Think about water distribution networks or computational materials science. And you will have no less amount of interesting and valuable problems to work on.

Photo by jimpg2_2015

The first thing that we need to understand is that how methods receive and return inputs and outputs (IO). This is very important. The working of a method can be broadly divided into two types of tasks. One is to handle IO. The other is to manipulate inputs to generate outputs. This article particularly reflects on the first part i.e. how a method deals with IO.

To understand this, it will be very nice to remind ourselves that in Java all arguments to a method are passed by value. What this literally means is that if we have a variable ‘x’ to which we have assigned a value of ‘6’, and if we pass this variable as an input argument to some method (e.g. insertX(x)), then its value (6) is passed to the method call insertX(x);.

This is true about all sorts of method calls in Java, and all sorts of data types including primitive and abstract. But we need to understand a few more things about abstract or user-defined data types.

Consider the following variable declaration in Java:

int x=5;

The above declaration creates a variable of type int and assigns it a value of 5. x goes on the stack.

Now consider the following variable declaration:

MyDataType data;

The above declaration creates a variable of type MyDataType, which is essentially a user-defined data type. What is ‘data’? Well, data is a variable. Where is it located? It is located on the stack. What is its value? It hasn’t been assigned any value yet. How to assign a value to it? Following is the procedure for that.

data= new MyDataType();

What we have done above essentially is that we have created an object of type MyDataType (on the right-hand side of the expression). This object is allocated memory on heap since this is dynamic memory allocation (all dynamic memory allocation is done on the heap). The object does not have any name as such. However, it does have an address. And its address gets assigned to ‘data’ (left-hand side of the expression).

So the value of ‘data’ now is the address of the newly created object of type MyDataType.

Now, consider a method that accepts an object of type ‘MyDataType’. Let us consider the following method, for instance.

public class Example{
//
//

public MyDataType insertData(MyDataType data){
//
//
return data;
}
}

The method ‘insertData’ accepts an argument of type ‘MyDataType’. It also returns an argument of type MyDataType.

Now consider the following method call.

MyDataType data2=insertData(data);

where data is the variable mentioned and explained two paras above. Since Java is pass-by-value,  when we pass ‘data’ to ‘insertData()’, essentially we are passing the value of ‘data’ to the latter. But what is the value of ‘data’? Its value is the address of the object of type ‘MyDataType’, to which it is referring.

So the crux of the story is that when you are passing arguments of user-defined data types to Java methods, you are not passing the objects as such. In stead of this, you are actually always passing references to those objects. The actual objects keep on lying on the heap. Their references, that are stored in variables of the same type that are on stack get passed to methods. Same is true about return values. Objects are never returned. Instead, their references are returned. Through the references, objects can be manipulated as they keep lying on the heap.

This idea and its understanding can have a profound impact on your programming skills. Once you have developed skeleton code, the next thing you have to deal with is IO in methods. Once this is understood, rest of the stuff becomes easier to comprehend and implement.

Photo by Plutor

I am going to reflect on one less obvious but extremely useful benefit of patterns. It may happen often in your career as a software developer or a software engineer that you may be enticed to use an already developed piece of software for your project. You might be required to develop something specific and you may find that parts of what you want to develop can be addressed by using open source software that is available online. This can be a great help for you as you may not have to rewrite the code.

A good example that comes to my mind is that you want to develop an ecosystem simulation toolkit. Instead of developing everything from scratch, you may find a certain library online that provides good simulation of a certain family of animals. Or you may find online a nice library or framework that simulates the environment in a realistic manner. Depending upon the quality of software, you may definitely be compelled to use it.

But as soon as you download it and dive into its code you may be overwhelmed by its code. It may begin to sound like a labyrinth of objects and classes scattered all over the files. This may leave you clueless as to how to actually get a handle to it and finally use it.

Normally all good software comes with its associated design document. You may have access to the class and uml diagrams and a user’s manual. This can come in handy for you to be able to use the software. Normally all good software has design pa

Normally all good software also has design patterns applied to it as well. If you have the basic knowledge of how design patterns work, their basic functionality, and what purpose different patterns serves, you may find it very easy and convenient to manipulate your desired software.

Basically, design patterns are templates that you apply to your software during the design time. When you convert your software to code, finally, design patterns convert into patches and wrappers to your software. Normally they hide behind themselves the intricate details of objects they are applied to. As a result, they provide an easy to use interface to the developer. The developer, in turn, can use them to grab the desired objects.

Reusing already developed code cannot only be enticing, it can be very useful. There is loads of software that is present online that you can use to your advantage. But the most daunting aspect of the code that has been developed by someone else is to develop an understanding of it. Every developer can have his/her own peculiar style of coding. This can make it difficult for others to comprehend the code. If design patterns have been applied effectively, and if you have a decent knowledge of them and the so-called pattern language, it may become very easy for you to manipulate it. In turn, you may become a valuable software engineer.

Consider now the possible benefits you could have as a software engineer depending upon your knowledge of patterns and your coding skills.

1. No knowledge of patterns and bad coding skills: With bad coding skills and no knowledge of patterns, your life as a software developer will be quite difficult. You may have to struggle a lot and even get fired from your position if you do not enhance your skills.
2. Some knowledge of patterns and ordinary coding skills: Even with a little knowledge of patterns and ordinary coding skills, you will be able to manipulate off the shelf code really easily. I have argued about it above.
3. Good coding skills and no knowledge of patterns: If you have good coding skills but no knowledge of patterns, you will again have to struggle when manipulating off the shelf code. You would be clueless as to what patterns have been applied to which part of the code.
4. Decent knowledge of patterns and good coding skills: This is the ideal combination of skill levels to have. And the reasons are quite self-explanatory.

Photo by kudumomo

The 7 Best Prototyping Tools for UI and UX Designers in 2018

It is undoubted that UI/UX design is an important aspect of making a website or application work. Creating and improving products based on prototypes is growing in strength and the prototyping tools…

Top 29 Mockup and Wireframing Tools for Developers | ProfitBricks Blog

I remember I read a research paper a few years ago in which the authors had employed a genetic algorithm for identifying bugs in a piece of software. The algorithm works by generating a large population of individuals. Each one of them is a valid input to the program. By valid I mean something that the program can accept as input. So the search space is the set of all the valid inputs to the program at hand.

The algorithm evaluates all the individuals by seeing how the program works as they are input to it. On the inputs on which the program crashes, the algorithm uses them to evolve further generations. This is how the algorithm narrows down on the search space and moves to the regions which generate inputs that crash the program. On further inspection of the inputs, the user may learn about the patches of the code of the program that may have caused crashes. The bugs can then be fixed easily.

The talking I am talking about was quite old. I guess it was written in the late 90s’ by a few researchers in the Norway’s Trondheim University of Technology.

The scheme was elegant nonetheless. It reduces a lot of labor on part of the software engineer as the process of bug testing is automated.

Search based software engineering is a matured field now. Every now and then I get an email about a call for papers from a conference, symposium or a workshop being held on evolutionary computation and there is almost always a track for search based software engineering.

Here I am posting a few links that might be of interest to anyone who is willing to work in this area.

Here is a link on GECCO’s website about its track on search based software engineering.

GECCO 2017 | Program Tracks

This is a link about an independent symposium that is held about this topic.

http://ssbse.org/2016/

Evostar conferences are leading European conferences about various topics in theory and applications of machine learning. Here is a link to their conference of software engineering.

http://www.evostar.org/2017/cfp_evoset.php

I shall keep on finding and posting more valuable stuff on this topic here.

Photo by ikewinski